Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

[Maarten Lankhorst]

Op 16-12-16 om 14:17 schreef Nicolai Hähnle:
> On 06.12.2016 16:25, Peter Zijlstra wrote:
>> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
>>
>>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, 
>>> unsigned int subclass,
>>>  struct mutex_waiter waiter;
>>>  unsigned long flags;
>>>  bool first = false;
>>> -struct ww_mutex *ww;
>>>  int ret;
>>>
>>> -if (use_ww_ctx) {
>>> +if (use_ww_ctx && ww_ctx) {
>>> +struct ww_mutex *ww;
>>> +
>>>  ww = container_of(lock, struct ww_mutex, base);
>>>  if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
>>>  return -EALREADY;
>>
>> So I don't see the point of removing *ww from the function scope, we can
>> still compute that container_of() even if !ww_ctx, right? That would
>> safe a ton of churn below, adding all those struct ww_mutex declarations
>> and container_of() casts.
>>
>> (and note that the container_of() is a fancy NO-OP because base is the
>> first member).
>
> Sorry for taking so long to get back to you.
>
> In my experience, the undefined behavior sanitizer in GCC for userspace 
> programs complains about merely casting a pointer to the wrong type. I never 
> went into the standards rabbit hole to figure out the details. It might be a 
> C++ only thing (ubsan cannot tell the difference otherwise anyway), but that 
> was the reason for doing the change in this more complicated way.
>
> Are you sure that this is defined behavior in C? If so, I'd be happy to go 
> with the version that has less churn.
>
> I'll also get rid of those ww_mutex_lock* wrapper functions. 

ww_ctx = use_ww_ctx ? container_of : NULL ?

Re: [PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

[Maarten Lankhorst]

Op 16-12-16 om 14:17 schreef Nicolai Hähnle:
> On 06.12.2016 16:25, Peter Zijlstra wrote:
>> On Thu, Dec 01, 2016 at 03:06:47PM +0100, Nicolai Hähnle wrote:
>>
>>> @@ -640,10 +640,11 @@ __mutex_lock_common(struct mutex *lock, long state, 
>>> unsigned int subclass,
>>>  struct mutex_waiter waiter;
>>>  unsigned long flags;
>>>  bool first = false;
>>> -struct ww_mutex *ww;
>>>  int ret;
>>>
>>> -if (use_ww_ctx) {
>>> +if (use_ww_ctx && ww_ctx) {
>>> +struct ww_mutex *ww;
>>> +
>>>  ww = container_of(lock, struct ww_mutex, base);
>>>  if (unlikely(ww_ctx == READ_ONCE(ww->ctx)))
>>>  return -EALREADY;
>>
>> So I don't see the point of removing *ww from the function scope, we can
>> still compute that container_of() even if !ww_ctx, right? That would
>> safe a ton of churn below, adding all those struct ww_mutex declarations
>> and container_of() casts.
>>
>> (and note that the container_of() is a fancy NO-OP because base is the
>> first member).
>
> Sorry for taking so long to get back to you.
>
> In my experience, the undefined behavior sanitizer in GCC for userspace 
> programs complains about merely casting a pointer to the wrong type. I never 
> went into the standards rabbit hole to figure out the details. It might be a 
> C++ only thing (ubsan cannot tell the difference otherwise anyway), but that 
> was the reason for doing the change in this more complicated way.
>
> Are you sure that this is defined behavior in C? If so, I'd be happy to go 
> with the version that has less churn.
>
> I'll also get rid of those ww_mutex_lock* wrapper functions. 

ww_ctx = use_ww_ctx ? container_of : NULL ?

Re: [RFC PATCH 06/14] sparc64: general shared context tsb creation and support

[Sam Ravnborg]

Hi Mike

> --- a/arch/sparc/mm/hugetlbpage.c
> +++ b/arch/sparc/mm/hugetlbpage.c
> @@ -162,8 +162,14 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long 
> addr,
>  {
>   pte_t orig;
>  
> - if (!pte_present(*ptep) && pte_present(entry))
> - mm->context.hugetlb_pte_count++;
> + if (!pte_present(*ptep) && pte_present(entry)) {
> +#if defined(CONFIG_SHARED_MMU_CTX)
> + if (pte_val(entry) | _PAGE_SHR_CTX_4V)
> + mm->context.shared_hugetlb_pte_count++;
> + else
> +#endif
> + mm->context.hugetlb_pte_count++;
> + }

This kind of conditional code it just too ugly to survive...
Could a static inline be used to help you here?
The compiler will inline it so there should not be any run-time cost

>  
>   mm_rss -= saved_thp_pte_count * (HPAGE_SIZE / PAGE_SIZE);
>  #endif
> @@ -544,8 +576,10 @@ int init_new_context(struct task_struct *tsk, struct 
> mm_struct *mm)
>* us, so we need to zero out the TSB pointer or else tsb_grow()
>* will be confused and think there is an older TSB to free up.
>*/
> - for (i = 0; i < MM_NUM_TSBS; i++)
> + for (i = 0; i < MM_NUM_TSBS; i++) {
>   mm->context.tsb_block[i].tsb = NULL;
> + mm->context.tsb_descr[i].tsb_base = 0UL;
> + }
This change seems un-related to the rest?

Sam

Re: [RFC PATCH 06/14] sparc64: general shared context tsb creation and support

[Sam Ravnborg]

Hi Mike

> --- a/arch/sparc/mm/hugetlbpage.c
> +++ b/arch/sparc/mm/hugetlbpage.c
> @@ -162,8 +162,14 @@ void set_huge_pte_at(struct mm_struct *mm, unsigned long 
> addr,
>  {
>   pte_t orig;
>  
> - if (!pte_present(*ptep) && pte_present(entry))
> - mm->context.hugetlb_pte_count++;
> + if (!pte_present(*ptep) && pte_present(entry)) {
> +#if defined(CONFIG_SHARED_MMU_CTX)
> + if (pte_val(entry) | _PAGE_SHR_CTX_4V)
> + mm->context.shared_hugetlb_pte_count++;
> + else
> +#endif
> + mm->context.hugetlb_pte_count++;
> + }

This kind of conditional code it just too ugly to survive...
Could a static inline be used to help you here?
The compiler will inline it so there should not be any run-time cost

>  
>   mm_rss -= saved_thp_pte_count * (HPAGE_SIZE / PAGE_SIZE);
>  #endif
> @@ -544,8 +576,10 @@ int init_new_context(struct task_struct *tsk, struct 
> mm_struct *mm)
>* us, so we need to zero out the TSB pointer or else tsb_grow()
>* will be confused and think there is an older TSB to free up.
>*/
> - for (i = 0; i < MM_NUM_TSBS; i++)
> + for (i = 0; i < MM_NUM_TSBS; i++) {
>   mm->context.tsb_block[i].tsb = NULL;
> + mm->context.tsb_descr[i].tsb_base = 0UL;
> + }
This change seems un-related to the rest?

Sam

Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1

[Sam Ravnborg]

Hi Mike

> diff --git a/arch/sparc/kernel/fpu_traps.S b/arch/sparc/kernel/fpu_traps.S
> index 336d275..f85a034 100644
> --- a/arch/sparc/kernel/fpu_traps.S
> +++ b/arch/sparc/kernel/fpu_traps.S
> @@ -73,6 +73,16 @@ do_fpdis:
>   ldxa[%g3] ASI_MMU, %g5
>   .previous
>  
> +661: nop
> + nop
> + .section.sun4v_2insn_patch, "ax"
> + .word   661b
> + mov SECONDARY_CONTEXT_R1, %g3
> + ldxa[%g3] ASI_MMU, %g4
> + .previous
> + /* Unnecessary on sun4u and pre-Niagara 2 sun4v */
> + mov SECONDARY_CONTEXT, %g3
> +
>   sethi   %hi(sparc64_kern_sec_context), %g2

You missed the second instruction to patch with here.
This bug repeats itself further down.

Just noted while briefly reading the code - did not really follow the code.

Sam

Re: [RFC PATCH 04/14] sparc64: load shared id into context register 1

[Sam Ravnborg]

Hi Mike

> diff --git a/arch/sparc/kernel/fpu_traps.S b/arch/sparc/kernel/fpu_traps.S
> index 336d275..f85a034 100644
> --- a/arch/sparc/kernel/fpu_traps.S
> +++ b/arch/sparc/kernel/fpu_traps.S
> @@ -73,6 +73,16 @@ do_fpdis:
>   ldxa[%g3] ASI_MMU, %g5
>   .previous
>  
> +661: nop
> + nop
> + .section.sun4v_2insn_patch, "ax"
> + .word   661b
> + mov SECONDARY_CONTEXT_R1, %g3
> + ldxa[%g3] ASI_MMU, %g4
> + .previous
> + /* Unnecessary on sun4u and pre-Niagara 2 sun4v */
> + mov SECONDARY_CONTEXT, %g3
> +
>   sethi   %hi(sparc64_kern_sec_context), %g2

You missed the second instruction to patch with here.
This bug repeats itself further down.

Just noted while briefly reading the code - did not really follow the code.

Sam

Re: [RFC PATCH 02/14] sparc64: add new fields to mmu context for shared context support

[Sam Ravnborg]

Hi Mike

> diff --git a/arch/sparc/include/asm/mmu_context_64.h 
> b/arch/sparc/include/asm/mmu_context_64.h
> index b84be67..d031799 100644
> --- a/arch/sparc/include/asm/mmu_context_64.h
> +++ b/arch/sparc/include/asm/mmu_context_64.h
> @@ -35,15 +35,15 @@ void __tsb_context_switch(unsigned long pgd_pa,
>  static inline void tsb_context_switch(struct mm_struct *mm)
>  {
>   __tsb_context_switch(__pa(mm->pgd),
> -  >context.tsb_block[0],
> +  >context.tsb_block[MM_TSB_BASE],
>  #if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
> -  (mm->context.tsb_block[1].tsb ?
> -   >context.tsb_block[1] :
> +  (mm->context.tsb_block[MM_TSB_HUGE].tsb ?
> +   >context.tsb_block[MM_TSB_HUGE] :
> NULL)
>  #else
>NULL
>  #endif
> -  , __pa(>context.tsb_descr[0]));
> +  , __pa(>context.tsb_descr[MM_TSB_BASE]));
>  }
>  
This is a nice cleanup that has nothing to do with your series.
Could you submit this as a separate patch so we can get it applied.

This is the only place left where the array index for tsb_block
and tsb_descr uses hardcoded values. And it would be good to get
rid of these.

Sam

Re: [RFC PATCH 02/14] sparc64: add new fields to mmu context for shared context support

[Sam Ravnborg]

Hi Mike

> diff --git a/arch/sparc/include/asm/mmu_context_64.h 
> b/arch/sparc/include/asm/mmu_context_64.h
> index b84be67..d031799 100644
> --- a/arch/sparc/include/asm/mmu_context_64.h
> +++ b/arch/sparc/include/asm/mmu_context_64.h
> @@ -35,15 +35,15 @@ void __tsb_context_switch(unsigned long pgd_pa,
>  static inline void tsb_context_switch(struct mm_struct *mm)
>  {
>   __tsb_context_switch(__pa(mm->pgd),
> -  >context.tsb_block[0],
> +  >context.tsb_block[MM_TSB_BASE],
>  #if defined(CONFIG_HUGETLB_PAGE) || defined(CONFIG_TRANSPARENT_HUGEPAGE)
> -  (mm->context.tsb_block[1].tsb ?
> -   >context.tsb_block[1] :
> +  (mm->context.tsb_block[MM_TSB_HUGE].tsb ?
> +   >context.tsb_block[MM_TSB_HUGE] :
> NULL)
>  #else
>NULL
>  #endif
> -  , __pa(>context.tsb_descr[0]));
> +  , __pa(>context.tsb_descr[MM_TSB_BASE]));
>  }
>  
This is a nice cleanup that has nothing to do with your series.
Could you submit this as a separate patch so we can get it applied.

This is the only place left where the array index for tsb_block
and tsb_descr uses hardcoded values. And it would be good to get
rid of these.

Sam

Re: [RFC PATCH 02/14] sparc64: add new fields to mmu context for shared context support

[Sam Ravnborg]

Hi Mike.

On Fri, Dec 16, 2016 at 10:35:25AM -0800, Mike Kravetz wrote:
> Add new fields to the mm_context structure to support shared context.
> Instead of a simple context ID, add a pointer to a structure with a
> reference count.  This is needed as multiple tasks will share the
> context ID.

What are the benefits with the shared_mmu_ctx struct?
It does not save any space in mm_context_t, and the CPU only
supports one extra context.
So it looks like over-engineering with all the extra administration
required to handle it with refcount, poitners etc.

what do I miss?

Sam

Re: [RFC PATCH 02/14] sparc64: add new fields to mmu context for shared context support

[Sam Ravnborg]

Hi Mike.

On Fri, Dec 16, 2016 at 10:35:25AM -0800, Mike Kravetz wrote:
> Add new fields to the mm_context structure to support shared context.
> Instead of a simple context ID, add a pointer to a structure with a
> reference count.  This is needed as multiple tasks will share the
> context ID.

What are the benefits with the shared_mmu_ctx struct?
It does not save any space in mm_context_t, and the CPU only
supports one extra context.
So it looks like over-engineering with all the extra administration
required to handle it with refcount, poitners etc.

what do I miss?

Sam

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

[Anand Moon]

Hi Markus,

On 16 December 2016 at 14:38, Markus Reichl  wrote:
> Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
>> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
 [ I added Arjun to Cc:, maybe he can help in explaining this issue
   (unfortunately Inderpal's email is no longer working). ]

 Please also note that on Exynos5422/5800 SoCs the same ARM rail
 voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
 IOW if the problem exists it is already present in the mainline
 kernel.
>>>
>>> Interesting.  In the ChromeOS tree I see significantly higher voltages
>>> needed...  Note that one might naively look at
>>> .
>>>
>>> 1362500, /* L0  2100 */
>>> 1312500, /* L1  2000 */
>>>
>>> ..but, amazingly enough those voltages aren't used at all.  Surprise!
>>>
>>> I believe that the above numbers are actually not used and the ASV
>>> numbers are used instead.  See
>>> 
>>>
>>> { 210,
>>> 135, 135, 135, 135, 135,
>>> 1337500, 1325000, 1312500, 130, 1287500,
>>> 1275000, 1262500, 125, 1237500 },
>>>
>>> I believe that interpretation there is: some bins of the CPU can run
>>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>>
>> That is definitely the case. One could just look at vendors ASV table
>> (for 1.9 GHz):
>> { 190, 130, 1287500, 1262500, 1237500, 1225000, 1212500,
>> 120, 1187500, 1175000, 1162500, 115,
>>1137500, 1125000, 1112500, 1112500},
>>
>> The theoretical difference is up to 1.875V! From my experiments I saw
>> BIN1 chips which should be the same... but some working on 1.2V, some on
>> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
>> does not mean that there aren't such...
>>
>>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>>> running on a CPU from a nice bin?
>
> I've been running the proposed frequency/voltage combinations without any
> stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
> nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
> The chips are poorly cooled, especially the XU4 and quickly step down.

[snip]

As per my knowlegde Odroid XU3/4 can throttle at much high temperature.

https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/drivers/thermal/exynos_thermal.c#L1629

The device tree binding for thermal-zone is kept bit low alert
temperature values
in-order to avoid reaches critical temperature and board shutdown
when compiling the source code. We need t fix this thermal-zone

Their could be some race in thermal or the step wise governor for
exynos is not working correctly.

Better option is to print the cpufreq for cpu0 and cpu4 and respective temp
and plot a graph along timeline. It will give us clear idea on how much
time is spend on high frequency on stress testing.

#!/bin/bash
t=0
while true :
do
 a=`cat /sys/devices/virtual/thermal/thermal_zone0/temp`
 b=`cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq`
 c=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq`
 d=`cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq`
 e=`cat /sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_cur_freq`
 (( t += 5 ))
 echo $t,$a,$b,$d,$e
 sleep 1
done

Best Regards
-Anand Moon

Re: [PATCH] ARM: dts: Add missing CPU frequencies for Exynos5422/5800

[Anand Moon]

Hi Markus,

On 16 December 2016 at 14:38, Markus Reichl  wrote:
> Am 16.12.2016 um 08:37 schrieb Krzysztof Kozlowski:
>> On Thu, Dec 15, 2016 at 04:52:58PM -0800, Doug Anderson wrote:
 [ I added Arjun to Cc:, maybe he can help in explaining this issue
   (unfortunately Inderpal's email is no longer working). ]

 Please also note that on Exynos5422/5800 SoCs the same ARM rail
 voltage is used for 1.9 GHz & 2.0 GHz OPPs as for the 1.8 GHz one.
 IOW if the problem exists it is already present in the mainline
 kernel.
>>>
>>> Interesting.  In the ChromeOS tree I see significantly higher voltages
>>> needed...  Note that one might naively look at
>>> .
>>>
>>> 1362500, /* L0  2100 */
>>> 1312500, /* L1  2000 */
>>>
>>> ..but, amazingly enough those voltages aren't used at all.  Surprise!
>>>
>>> I believe that the above numbers are actually not used and the ASV
>>> numbers are used instead.  See
>>> 
>>>
>>> { 210,
>>> 135, 135, 135, 135, 135,
>>> 1337500, 1325000, 1312500, 130, 1287500,
>>> 1275000, 1262500, 125, 1237500 },
>>>
>>> I believe that interpretation there is: some bins of the CPU can run
>>> at 2.1 GHz just fine at 1.25 V but others need up to 1.35V.
>>
>> That is definitely the case. One could just look at vendors ASV table
>> (for 1.9 GHz):
>> { 190, 130, 1287500, 1262500, 1237500, 1225000, 1212500,
>> 120, 1187500, 1175000, 1162500, 115,
>>1137500, 1125000, 1112500, 1112500},
>>
>> The theoretical difference is up to 1.875V! From my experiments I saw
>> BIN1 chips which should be the same... but some working on 1.2V, some on
>> 1.225V (@1.9 GHz). I didn't see any requiring higher voltages but that
>> does not mean that there aren't such...
>>
>>> ...so if you're running at 2.1 GHz at 1.25V then perhaps you're just
>>> running on a CPU from a nice bin?
>
> I've been running the proposed frequency/voltage combinations without any
> stability problems on my XU4, XU3 and even XU3-lite ( I did not delete the
> nodes on XU3-lite dts) with make -j8 kernel and ssvb-cpuburn.
> The chips are poorly cooled, especially the XU4 and quickly step down.

[snip]

As per my knowlegde Odroid XU3/4 can throttle at much high temperature.

https://github.com/hardkernel/linux/blob/odroidxu3-3.10.y/drivers/thermal/exynos_thermal.c#L1629

The device tree binding for thermal-zone is kept bit low alert
temperature values
in-order to avoid reaches critical temperature and board shutdown
when compiling the source code. We need t fix this thermal-zone

Their could be some race in thermal or the step wise governor for
exynos is not working correctly.

Better option is to print the cpufreq for cpu0 and cpu4 and respective temp
and plot a graph along timeline. It will give us clear idea on how much
time is spend on high frequency on stress testing.

#!/bin/bash
t=0
while true :
do
 a=`cat /sys/devices/virtual/thermal/thermal_zone0/temp`
 b=`cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq`
 c=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq`
 d=`cat /sys/devices/system/cpu/cpu4/cpufreq/scaling_cur_freq`
 e=`cat /sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_cur_freq`
 (( t += 5 ))
 echo $t,$a,$b,$d,$e
 sleep 1
done

Best Regards
-Anand Moon

Re: i2c: xiic: Strange clk_prepare_enable() in xiic_i2c_remove()

[Shubhrajyoti Datta]

On Sat, Dec 17, 2016 at 3:24 AM, Alexey Khoroshilov
 wrote:
> Dear Shubhrajyoti,
>
> Looking at 36ecbcab84d0 ("i2c: xiic: Implement power management")
> it is not clear why clk_prepare_enable(i2c->clk) is required in
> xiic_i2c_remove()?

834 ret = clk_prepare_enable(i2c->clk);
835 if (ret) {
836 dev_err(>dev, "Unable to enable clock.\n");
837 return ret;
838 }
839 xiic_deinit(i2c);
840 clk_disable_unprepare(i2c->clk);

so it is enabled and disabled after xiic_deinit.

>
> It is enabled in xiic_i2c_probe() and disabled/enabled in
> cdns_i2c_runtime_suspend()/cdns_i2c_runtime_resume().
>
> Could you please clarify the point.
>
> --
> Alexey Khoroshilov
> Linux Verification Center, ISPRAS
> web: http://linuxtesting.org
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: i2c: xiic: Strange clk_prepare_enable() in xiic_i2c_remove()

[Shubhrajyoti Datta]

On Sat, Dec 17, 2016 at 3:24 AM, Alexey Khoroshilov
 wrote:
> Dear Shubhrajyoti,
>
> Looking at 36ecbcab84d0 ("i2c: xiic: Implement power management")
> it is not clear why clk_prepare_enable(i2c->clk) is required in
> xiic_i2c_remove()?

834 ret = clk_prepare_enable(i2c->clk);
835 if (ret) {
836 dev_err(>dev, "Unable to enable clock.\n");
837 return ret;
838 }
839 xiic_deinit(i2c);
840 clk_disable_unprepare(i2c->clk);

so it is enabled and disabled after xiic_deinit.

>
> It is enabled in xiic_i2c_probe() and disabled/enabled in
> cdns_i2c_runtime_suspend()/cdns_i2c_runtime_resume().
>
> Could you please clarify the point.
>
> --
> Alexey Khoroshilov
> Linux Verification Center, ISPRAS
> web: http://linuxtesting.org
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Document accounting of FDs passed over UNIX domain sockets

[Willy Tarreau]

Hi Michael,

On Fri, Dec 16, 2016 at 12:08:33PM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Willy,
> 
> Your commit 712f4aad406bb1 ("unix: properly account for FDs passed over 
> unix sockets" added accounting to ensure that the RLIMIT_NOFILE limit
> could not be bypassed when passing file descriptors across UNIX
> domain sockets.
> 
> Such patches should be CCed to linux-...@vger.kernel.org ;-)

Yes, I learned this after your presentation at kernel recipes, but this
patch pre-dates it ;-)

> A documentation [atch would be great as well, but I had a shot 
> at cobbling some text together. Does the text below (for the unix(7)
> man page) look okay?

I think so, though maybe we can arrange it very slightly given that
this was considered as a fix for a vulnerability and backported to
various kernels :

>ETOOMANYREFS
>   This  error  can  occur  for sendmsg(2) when sending a file
>   descriptor as ancilary data over a UNIX domain socket  (see
>   the  description  of  SCM_RIGHTS, above).  It occurs if the
>   number  of  "in-flight"  file   descriptors   exceeds   the
>   RLIMIT_NOFILE  resource  limit and the caller does not have
>   the  CAP_SYS_RESOURCE  capability.An   in-flight   file
>   descriptor  is  one that has been sent using sendmsg(2) but
>   has not yet been accepted in the  recipient  process  using
>   recvmsg(2).
> 
>   This error is diagnosed since Linux 4.5.  In earlier kernel
>   versions, it was possible to place an unlimited  number  of
>   file descriptors in flight, by sending each file descriptor
>   with sendmsg(2) and then closing  the  file  descriptor  so
>   that   it  was  not  accounted  against  the  RLIMIT_NOFILE
>   resource limit.

-   resource limit.
+   resource limit. Some older stable kernels might have
+   included the same check by backporting the fix from 4.5.

I've just checked the exact versions containing this, but I don't think
it's worth providing the list, in my opinion mentionning that it could be
observed on some older versions is enough to help developers who see it
in field :
  - 3.2.78
  - 3.10.99
  - 3.12.57
  - 3.14.63
  - 3.16.35
  - 3.18.27
  - 4.1.19
  - 4.4.4

Best regards,
Willy

Re: Document accounting of FDs passed over UNIX domain sockets

[Willy Tarreau]

Hi Michael,

On Fri, Dec 16, 2016 at 12:08:33PM +0100, Michael Kerrisk (man-pages) wrote:
> Hello Willy,
> 
> Your commit 712f4aad406bb1 ("unix: properly account for FDs passed over 
> unix sockets" added accounting to ensure that the RLIMIT_NOFILE limit
> could not be bypassed when passing file descriptors across UNIX
> domain sockets.
> 
> Such patches should be CCed to linux-...@vger.kernel.org ;-)

Yes, I learned this after your presentation at kernel recipes, but this
patch pre-dates it ;-)

> A documentation [atch would be great as well, but I had a shot 
> at cobbling some text together. Does the text below (for the unix(7)
> man page) look okay?

I think so, though maybe we can arrange it very slightly given that
this was considered as a fix for a vulnerability and backported to
various kernels :

>ETOOMANYREFS
>   This  error  can  occur  for sendmsg(2) when sending a file
>   descriptor as ancilary data over a UNIX domain socket  (see
>   the  description  of  SCM_RIGHTS, above).  It occurs if the
>   number  of  "in-flight"  file   descriptors   exceeds   the
>   RLIMIT_NOFILE  resource  limit and the caller does not have
>   the  CAP_SYS_RESOURCE  capability.An   in-flight   file
>   descriptor  is  one that has been sent using sendmsg(2) but
>   has not yet been accepted in the  recipient  process  using
>   recvmsg(2).
> 
>   This error is diagnosed since Linux 4.5.  In earlier kernel
>   versions, it was possible to place an unlimited  number  of
>   file descriptors in flight, by sending each file descriptor
>   with sendmsg(2) and then closing  the  file  descriptor  so
>   that   it  was  not  accounted  against  the  RLIMIT_NOFILE
>   resource limit.

-   resource limit.
+   resource limit. Some older stable kernels might have
+   included the same check by backporting the fix from 4.5.

I've just checked the exact versions containing this, but I don't think
it's worth providing the list, in my opinion mentionning that it could be
observed on some older versions is enough to help developers who see it
in field :
  - 3.2.78
  - 3.10.99
  - 3.12.57
  - 3.14.63
  - 3.16.35
  - 3.18.27
  - 4.1.19
  - 4.4.4

Best regards,
Willy

Re: Issue with DRM and "reimplement IDR and IDA using the radix tree"

[Alexandre Courbot]

On 12/17/2016 01:16 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Wed, Dec 14, 2016 at 11:08:20PM +0900, Alexandre Courbot wrote:
>> Forgot to add the most relevant list for this issue (linux-next).
>>
>> Stephen, maybe you will want to temporarily revert this patch until this
>> is cleared? This probably affects other users than DRM.
>>
>> On 12/13/2016 04:14 PM, Alexandre Courbot wrote:
>>> Hi Matthew,
>>>
>>> Trying the latest -next on the Jetson TK1 board (with two different DRM
>>> devices and display and render), I noticed that the GPU device probe
>>> always failed with error -ENOSPC. After investigating I figured out that
>>> this was due to the minor device allocation failing when a second DRM
>>> device is added.
>>>
>>> More precisely, when drm_minor_alloc() is called with DRM_MINOR_PRIMARY
>>> (0) as argument for a second time, the call to idr_alloc() (which has a
>>> requested range of 0..64) fails instead of returning 1 as expected. Note
>>> that the first call is successful.
>>>
>>> Reverting "reimplement IDR and IDA using the radix tree" on 20161213's
>>> next fixes the issue for me, suggesting a bug may have slipped in there.
>>>
>>> Not sure how this could be fixed, so reporting the issue for now in case
>>> it is not known yet.
> 
> I can confirm Alex' findings, though the symptoms seem to be slightly
> different, which may be related to me testing on next-20161216 rather
> than next-20161213.
> 
> What I'm seeing is that all drivers get probed correctly, but when an
> application tries to open the DRM device files (/dev/dri/card0 in this
> case), then all devices of a given minor type disappear. So in my case
> upon boot I get this:
> 
>   # ls -l /dev/dri/
>   total 0
>   crw-rw 1 root video 226,   0 Dec 16 15:59 card0
>   crw-rw 1 root video 226,   1 Dec 16 15:59 card1
>   crw-rw 1 root video 226, 128 Dec 16 15:59 renderD128
> 
> The modetest program from libdrm is then unable to open any devices:
> 
>   # modetest
>   trying to open device 'i915'...failed
>   trying to open device 'amdgpu'...failed
>   trying to open device 'radeon'...failed
>   trying to open device 'nouveau'...failed
>   trying to open device 'vmwgfx'...failed
>   trying to open device 'omapdrm'...failed
>   trying to open device 'exynos'...failed
>   trying to open device 'tilcdc'...failed
>   trying to open device 'msm'...failed
>   trying to open device 'sti'...failed
>   trying to open device 'tegra'...failed
>   trying to open device 'imx-drm'...failed
>   trying to open device 'rockchip'...failed
>   trying to open device 'atmel-hlcdc'...failed
>   trying to open device 'fsl-dcu-drm'...failed
>   trying to open device 'vc4'...failed
>   trying to open device 'virtio_gpu'...failed
>   trying to open device 'mediatek'...failed
>   no device found
> 
> And after that all of the primary minors are gone:
> 
>   # ls -l /dev/dri/
>   total 0
>   crw-rw 1 root video 226, 128 Dec 16 15:59 renderD128

That's exactly what I am also getting with 20161216. As it turns out the
patch has changed slightly (my revert did not apply after a rebase), and
the symptoms changed against 20161215, but the fix is the same:
reverting gives me back a working system.

This patch really should be reverted for now. Like Thierry I am
available to test further iterations.

Re: Issue with DRM and "reimplement IDR and IDA using the radix tree"

[Alexandre Courbot]

On 12/17/2016 01:16 AM, Thierry Reding wrote:
> * PGP Signed by an unknown key
> 
> On Wed, Dec 14, 2016 at 11:08:20PM +0900, Alexandre Courbot wrote:
>> Forgot to add the most relevant list for this issue (linux-next).
>>
>> Stephen, maybe you will want to temporarily revert this patch until this
>> is cleared? This probably affects other users than DRM.
>>
>> On 12/13/2016 04:14 PM, Alexandre Courbot wrote:
>>> Hi Matthew,
>>>
>>> Trying the latest -next on the Jetson TK1 board (with two different DRM
>>> devices and display and render), I noticed that the GPU device probe
>>> always failed with error -ENOSPC. After investigating I figured out that
>>> this was due to the minor device allocation failing when a second DRM
>>> device is added.
>>>
>>> More precisely, when drm_minor_alloc() is called with DRM_MINOR_PRIMARY
>>> (0) as argument for a second time, the call to idr_alloc() (which has a
>>> requested range of 0..64) fails instead of returning 1 as expected. Note
>>> that the first call is successful.
>>>
>>> Reverting "reimplement IDR and IDA using the radix tree" on 20161213's
>>> next fixes the issue for me, suggesting a bug may have slipped in there.
>>>
>>> Not sure how this could be fixed, so reporting the issue for now in case
>>> it is not known yet.
> 
> I can confirm Alex' findings, though the symptoms seem to be slightly
> different, which may be related to me testing on next-20161216 rather
> than next-20161213.
> 
> What I'm seeing is that all drivers get probed correctly, but when an
> application tries to open the DRM device files (/dev/dri/card0 in this
> case), then all devices of a given minor type disappear. So in my case
> upon boot I get this:
> 
>   # ls -l /dev/dri/
>   total 0
>   crw-rw 1 root video 226,   0 Dec 16 15:59 card0
>   crw-rw 1 root video 226,   1 Dec 16 15:59 card1
>   crw-rw 1 root video 226, 128 Dec 16 15:59 renderD128
> 
> The modetest program from libdrm is then unable to open any devices:
> 
>   # modetest
>   trying to open device 'i915'...failed
>   trying to open device 'amdgpu'...failed
>   trying to open device 'radeon'...failed
>   trying to open device 'nouveau'...failed
>   trying to open device 'vmwgfx'...failed
>   trying to open device 'omapdrm'...failed
>   trying to open device 'exynos'...failed
>   trying to open device 'tilcdc'...failed
>   trying to open device 'msm'...failed
>   trying to open device 'sti'...failed
>   trying to open device 'tegra'...failed
>   trying to open device 'imx-drm'...failed
>   trying to open device 'rockchip'...failed
>   trying to open device 'atmel-hlcdc'...failed
>   trying to open device 'fsl-dcu-drm'...failed
>   trying to open device 'vc4'...failed
>   trying to open device 'virtio_gpu'...failed
>   trying to open device 'mediatek'...failed
>   no device found
> 
> And after that all of the primary minors are gone:
> 
>   # ls -l /dev/dri/
>   total 0
>   crw-rw 1 root video 226, 128 Dec 16 15:59 renderD128

That's exactly what I am also getting with 20161216. As it turns out the
patch has changed slightly (my revert did not apply after a rebase), and
the symptoms changed against 20161215, but the fix is the same:
reverting gives me back a working system.

This patch really should be reverted for now. Like Thierry I am
available to test further iterations.

Re: [PATCH] spi: rockchip: support "sleep" pin configuration

[Doug Anderson]

Hi,

On Fri, Dec 16, 2016 at 4:59 PM, Brian Norris  wrote:
> In the pattern of many other devices, support a system-sleep pin
> configuration.
>
> Signed-off-by: Brian Norris 
> ---
>  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 7 +++
>  drivers/spi/spi-rockchip.c | 5 +
>  2 files changed, 12 insertions(+)

FWIW

Reviewed-by: Douglas Anderson 

Re: [PATCH] spi: rockchip: support "sleep" pin configuration

[Doug Anderson]

Hi,

On Fri, Dec 16, 2016 at 4:59 PM, Brian Norris  wrote:
> In the pattern of many other devices, support a system-sleep pin
> configuration.
>
> Signed-off-by: Brian Norris 
> ---
>  Documentation/devicetree/bindings/spi/spi-rockchip.txt | 7 +++
>  drivers/spi/spi-rockchip.c | 5 +
>  2 files changed, 12 insertions(+)

FWIW

Reviewed-by: Douglas Anderson 

[RFC][PATCH 1/5 v2] usb: dwc2: Avoid sleeping while holding hsotg->lock

[John Stultz]

Basically when plugging in various cables in different orders, I'm
occasionally seeing the following BUG splat:

[   86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x0002
[   86.219164] usb 1-1: USB disconnect, device number 9
[   86.226845] Preemption disabled at:[   86.230218]
[] dwc2_conn_id_status_change+0x120/0x250
[   86.236894] CPU: 0 PID: 53 Comm: kworker/u16:2 Tainted: GW
 4.9.0-rc8-00051-gd5a7979-dirty #1702
[   86.246836] Hardware name: HiKey Development Board (DT)
[   86.252100] Workqueue: dwc2 dwc2_conn_id_status_change
[   86.257279] Call trace:
[   86.259771] [] dump_backtrace+0x0/0x1a0
[   86.265210] [] show_stack+0x14/0x20
[   86.270308] [] dump_stack+0x90/0xb0
[   86.275401] [] __schedule_bug+0x6c/0xb8
[   86.280841] [] __schedule+0x4f8/0x5b0
[   86.286099] [] schedule+0x38/0xa0
[   86.291017] [] schedule_hrtimeout_range_clock+0x8c/0xf0
[   86.297846] [] schedule_hrtimeout_range+0x10/0x18
[   86.304150] [] usleep_range+0x50/0x58
[   86.309418] [] dwc2_wait_for_mode.isra.4+0x54/0xd0
[   86.315815] [] dwc2_core_reset+0xe0/0x168
[   86.321431] [] dwc2_hsotg_core_init_disconnected+0x2c/0x310
[   86.328602] [] dwc2_conn_id_status_change+0x130/0x250
[   86.335254] [] process_one_work+0x118/0x370
[   86.341035] [] worker_thread+0x48/0x498
[   86.346473] [] kthread+0xd0/0xe8
[   86.351299] [] ret_from_fork+0x10/0x50

This seems to be caused by the dwc2_wait_for_mode() calling
usleep_range() while the hstog->lock spinlock is held, since
we take that before calling dwc2_hsotg_core_init_disconnected().

This patch avoids the issue by adding an extra argument to
dwc2_core_reset(), as suggested by John Youn, which allows us to
skip the waiting, which should be unnecessary when calling from
dwc2_hsotg_core_init_disconnected().

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/core.c   | 6 +++---
 drivers/usb/dwc2/core.h   | 2 +-
 drivers/usb/dwc2/gadget.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 11d8ae9..2d0dac2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -313,7 +313,7 @@ static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg 
*hsotg)
  * Do core a soft reset of the core.  Be careful with this because it
  * resets all the internal state machines of the core.
  */
-int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait)
 {
u32 greset;
int count = 0;
@@ -369,7 +369,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));
 
-   if (wait_for_host_mode)
+   if (wait_for_host_mode && !skip_wait)
dwc2_wait_for_mode(hsotg, true);
 
return 0;
@@ -500,7 +500,7 @@ int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg 
*hsotg)
 {
int retval;
 
-   retval = dwc2_core_reset(hsotg);
+   retval = dwc2_core_reset(hsotg, false);
if (retval)
return retval;
 
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e..eb2d628 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1101,7 +1101,7 @@ static inline bool dwc2_is_hs_iot(struct dwc2_hsotg 
*hsotg)
  * The following functions support initialization of the core driver component
  * and the DWC_otg controller
  */
-extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
+extern int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait);
 extern int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg *hsotg);
 extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
 extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c55db4a..cbba471 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3158,7 +3158,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
 
if (!is_usb_reset)
-   if (dwc2_core_reset(hsotg))
+   if (dwc2_core_reset(hsotg, true))
return;
 
/*
-- 
2.7.4

[RFC][PATCH 0/5 v2] Fixes and workarounds for dwc2 on HiKey board

[John Stultz]

I just wanted to re-send my current queue of patches for dwc2
controller on the HiKey board, as my last patchset ended up
colliding with a number of changes that landed in the 4.10-rc
merge window. 

I've fixed things up and validated these against HiKey. I also
made a small change to one of the patches as suggested by Vardan.

This does exclude my patchset[1] to add extcon support to dwc2,
which John Youn suspects a pending rework of the dwc2 fifo init
logic might make unnecssary (however, no such changes appeared
to have landed in 4.10-rc, so I'm still using that patchset in
my testing).

I'm also out for the holidays after today, and while I suspect
others are likely going to be out as well, I figured I'd send
these out for a chance at review, rather then sit on them for
two weeks. I'll resend after the new year addressing any
feedback I do get though.

Feedback would be greatly appreciated!

thanks
-john

[1] https://lkml.org/lkml/2016/12/6/69

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org

Chen Yu (2):
  usb: dwc2: Force port resume on switching to device mode
  usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

John Stultz (3):
  usb: dwc2: Avoid sleeping while holding hsotg->lock
  usb: dwc2: Workaround case where GOTGCTL state is wrong
  usb: dwc2: Avoid suspending if we're in gadget mode

 drivers/usb/dwc2/core.c   |  6 ++--
 drivers/usb/dwc2/core.h   |  9 +-
 drivers/usb/dwc2/gadget.c |  2 +-
 drivers/usb/dwc2/hcd.c| 79 +++
 drivers/usb/dwc2/params.c | 19 
 5 files changed, 110 insertions(+), 5 deletions(-)

-- 
2.7.4

[RFC][PATCH 3/5 v2] usb: dwc2: Force port resume on switching to device mode

[John Stultz]

From: Chen Yu 

We've seen failures when switching between host and gadget mode,
which was diagnosed as being caused due to the bus being
auto-suspended when we switched.

So this patch forces a port resume when switching to device
mode if the bus is suspended.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index b60307a..a089946 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -54,6 +54,8 @@
 #include "core.h"
 #include "hcd.h"
 
+static void dwc2_port_resume(struct dwc2_hsotg *hsotg);
+
 /*
  * =
  *  Host Core Layer Functions
@@ -3235,6 +3237,11 @@ static void dwc2_conn_id_status_change(struct 
work_struct *work)
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
dev_dbg(hsotg->dev, "connId B\n");
+   if (hsotg->bus_suspended) {
+   dev_info(hsotg->dev,
+"Do port resume before switching to device 
mode\n");
+   dwc2_port_resume(hsotg);
+   }
while (!dwc2_is_device_mode(hsotg)) {
dev_info(hsotg->dev,
 "Waiting for Peripheral Mode, Mode=%s\n",
-- 
2.7.4

[RFC][PATCH 3/5 v2] usb: dwc2: Force port resume on switching to device mode

[John Stultz]

From: Chen Yu 

We've seen failures when switching between host and gadget mode,
which was diagnosed as being caused due to the bus being
auto-suspended when we switched.

So this patch forces a port resume when switching to device
mode if the bus is suspended.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index b60307a..a089946 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -54,6 +54,8 @@
 #include "core.h"
 #include "hcd.h"
 
+static void dwc2_port_resume(struct dwc2_hsotg *hsotg);
+
 /*
  * =
  *  Host Core Layer Functions
@@ -3235,6 +3237,11 @@ static void dwc2_conn_id_status_change(struct 
work_struct *work)
if (gotgctl & GOTGCTL_CONID_B) {
/* Wait for switch to device mode */
dev_dbg(hsotg->dev, "connId B\n");
+   if (hsotg->bus_suspended) {
+   dev_info(hsotg->dev,
+"Do port resume before switching to device 
mode\n");
+   dwc2_port_resume(hsotg);
+   }
while (!dwc2_is_device_mode(hsotg)) {
dev_info(hsotg->dev,
 "Waiting for Peripheral Mode, Mode=%s\n",
-- 
2.7.4

[RFC][PATCH 1/5 v2] usb: dwc2: Avoid sleeping while holding hsotg->lock

[John Stultz]

Basically when plugging in various cables in different orders, I'm
occasionally seeing the following BUG splat:

[   86.215403] BUG: scheduling while atomic: kworker/u16:2/53/0x0002
[   86.219164] usb 1-1: USB disconnect, device number 9
[   86.226845] Preemption disabled at:[   86.230218]
[] dwc2_conn_id_status_change+0x120/0x250
[   86.236894] CPU: 0 PID: 53 Comm: kworker/u16:2 Tainted: GW
 4.9.0-rc8-00051-gd5a7979-dirty #1702
[   86.246836] Hardware name: HiKey Development Board (DT)
[   86.252100] Workqueue: dwc2 dwc2_conn_id_status_change
[   86.257279] Call trace:
[   86.259771] [] dump_backtrace+0x0/0x1a0
[   86.265210] [] show_stack+0x14/0x20
[   86.270308] [] dump_stack+0x90/0xb0
[   86.275401] [] __schedule_bug+0x6c/0xb8
[   86.280841] [] __schedule+0x4f8/0x5b0
[   86.286099] [] schedule+0x38/0xa0
[   86.291017] [] schedule_hrtimeout_range_clock+0x8c/0xf0
[   86.297846] [] schedule_hrtimeout_range+0x10/0x18
[   86.304150] [] usleep_range+0x50/0x58
[   86.309418] [] dwc2_wait_for_mode.isra.4+0x54/0xd0
[   86.315815] [] dwc2_core_reset+0xe0/0x168
[   86.321431] [] dwc2_hsotg_core_init_disconnected+0x2c/0x310
[   86.328602] [] dwc2_conn_id_status_change+0x130/0x250
[   86.335254] [] process_one_work+0x118/0x370
[   86.341035] [] worker_thread+0x48/0x498
[   86.346473] [] kthread+0xd0/0xe8
[   86.351299] [] ret_from_fork+0x10/0x50

This seems to be caused by the dwc2_wait_for_mode() calling
usleep_range() while the hstog->lock spinlock is held, since
we take that before calling dwc2_hsotg_core_init_disconnected().

This patch avoids the issue by adding an extra argument to
dwc2_core_reset(), as suggested by John Youn, which allows us to
skip the waiting, which should be unnecessary when calling from
dwc2_hsotg_core_init_disconnected().

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/core.c   | 6 +++---
 drivers/usb/dwc2/core.h   | 2 +-
 drivers/usb/dwc2/gadget.c | 2 +-
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index 11d8ae9..2d0dac2 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -313,7 +313,7 @@ static bool dwc2_iddig_filter_enabled(struct dwc2_hsotg 
*hsotg)
  * Do core a soft reset of the core.  Be careful with this because it
  * resets all the internal state machines of the core.
  */
-int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait)
 {
u32 greset;
int count = 0;
@@ -369,7 +369,7 @@ int dwc2_core_reset(struct dwc2_hsotg *hsotg)
}
} while (!(greset & GRSTCTL_AHBIDLE));
 
-   if (wait_for_host_mode)
+   if (wait_for_host_mode && !skip_wait)
dwc2_wait_for_mode(hsotg, true);
 
return 0;
@@ -500,7 +500,7 @@ int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg 
*hsotg)
 {
int retval;
 
-   retval = dwc2_core_reset(hsotg);
+   retval = dwc2_core_reset(hsotg, false);
if (retval)
return retval;
 
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9548d3e..eb2d628 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -1101,7 +1101,7 @@ static inline bool dwc2_is_hs_iot(struct dwc2_hsotg 
*hsotg)
  * The following functions support initialization of the core driver component
  * and the DWC_otg controller
  */
-extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
+extern int dwc2_core_reset(struct dwc2_hsotg *hsotg, bool skip_wait);
 extern int dwc2_core_reset_and_force_dr_mode(struct dwc2_hsotg *hsotg);
 extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
 extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index c55db4a..cbba471 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -3158,7 +3158,7 @@ void dwc2_hsotg_core_init_disconnected(struct dwc2_hsotg 
*hsotg,
kill_all_requests(hsotg, hsotg->eps_out[0], -ECONNRESET);
 
if (!is_usb_reset)
-   if (dwc2_core_reset(hsotg))
+   if (dwc2_core_reset(hsotg, true))
return;
 
/*
-- 
2.7.4

[RFC][PATCH 0/5 v2] Fixes and workarounds for dwc2 on HiKey board

[John Stultz]

I just wanted to re-send my current queue of patches for dwc2
controller on the HiKey board, as my last patchset ended up
colliding with a number of changes that landed in the 4.10-rc
merge window. 

I've fixed things up and validated these against HiKey. I also
made a small change to one of the patches as suggested by Vardan.

This does exclude my patchset[1] to add extcon support to dwc2,
which John Youn suspects a pending rework of the dwc2 fifo init
logic might make unnecssary (however, no such changes appeared
to have landed in 4.10-rc, so I'm still using that patchset in
my testing).

I'm also out for the holidays after today, and while I suspect
others are likely going to be out as well, I figured I'd send
these out for a chance at review, rather then sit on them for
two weeks. I'll resend after the new year addressing any
feedback I do get though.

Feedback would be greatly appreciated!

thanks
-john

[1] https://lkml.org/lkml/2016/12/6/69

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org

Chen Yu (2):
  usb: dwc2: Force port resume on switching to device mode
  usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

John Stultz (3):
  usb: dwc2: Avoid sleeping while holding hsotg->lock
  usb: dwc2: Workaround case where GOTGCTL state is wrong
  usb: dwc2: Avoid suspending if we're in gadget mode

 drivers/usb/dwc2/core.c   |  6 ++--
 drivers/usb/dwc2/core.h   |  9 +-
 drivers/usb/dwc2/gadget.c |  2 +-
 drivers/usb/dwc2/hcd.c| 79 +++
 drivers/usb/dwc2/params.c | 19 
 5 files changed, 110 insertions(+), 5 deletions(-)

-- 
2.7.4

[RFC][PATCH 4/5 v2] usb: dwc2: Avoid suspending if we're in gadget mode

[John Stultz]

I've found when booting HiKey with the usb gadget cable attached
if I then try to connect via adb, I get an infinite spew of:

dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790ecb18 ep1out, 0)
dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790eca18 ep1in, 0)

It seems that the usb autosuspend is suspending the bus shortly
after bootup when the gadget cable is attached. So when adbd
then tries to use the device, it doesn't work and it then tries
to restart it over and over via the ep_sethalt calls (via
FUNCTIONFS_CLEAR_HALT ioctl).

Chen Yu suggested this patch to avoid suspending if we're
in device mode, and it avoids the problem.

This doesn't remove the need for the previous patch, to resume
the port when we switch to gadget mode from host mode. But it
does seem to resolve the issue.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Suggested-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index a089946..6e4ec8a 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4383,6 +4383,9 @@ static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
if (!HCD_HW_ACCESSIBLE(hcd))
goto unlock;
 
+   if (hsotg->op_state == OTG_STATE_B_PERIPHERAL)
+   goto unlock;
+
if (!hsotg->params.hibernation)
goto skip_power_saving;
 
-- 
2.7.4

[RFC][PATCH 4/5 v2] usb: dwc2: Avoid suspending if we're in gadget mode

[John Stultz]

I've found when booting HiKey with the usb gadget cable attached
if I then try to connect via adb, I get an infinite spew of:

dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790ecb18 ep1out, 0)
dwc2 f72c.usb: dwc2_hsotg_ep_sethalt(ep ffc0790eca18 ep1in, 0)

It seems that the usb autosuspend is suspending the bus shortly
after bootup when the gadget cable is attached. So when adbd
then tries to use the device, it doesn't work and it then tries
to restart it over and over via the ep_sethalt calls (via
FUNCTIONFS_CLEAR_HALT ioctl).

Chen Yu suggested this patch to avoid suspending if we're
in device mode, and it avoids the problem.

This doesn't remove the need for the previous patch, to resume
the port when we switch to gadget mode from host mode. But it
does seem to resolve the issue.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Suggested-by: Chen Yu 
Signed-off-by: John Stultz 
---
 drivers/usb/dwc2/hcd.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index a089946..6e4ec8a 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4383,6 +4383,9 @@ static int _dwc2_hcd_suspend(struct usb_hcd *hcd)
if (!HCD_HW_ACCESSIBLE(hcd))
goto unlock;
 
+   if (hsotg->op_state == OTG_STATE_B_PERIPHERAL)
+   goto unlock;
+
if (!hsotg->params.hibernation)
goto skip_power_saving;
 
-- 
2.7.4

[RFC][PATCH 2/5 v2] usb: dwc2: Workaround case where GOTGCTL state is wrong

[John Stultz]

When removing a USB-A to USB-otg adapter cable, we get a change
status irq, and then in dwc2_conn_id_status_change, we
erroniously see the GOTGCTL_CONID_B flag set. This causes us to
get  stuck in the "while (!dwc2_is_device_mode(hsotg))" loop,
spitting out "Waiting for Peripheral Mode, Mode=Host" warnings
until it fails out many seconds later.

This patch works around the issue by re-reading the GOTGCTL
state to check if the GOTGCTL_CONID_B is still set and if not
restarting the change status logic.

I suspect this isn't the best solution, but it seems to work
well for me.

Feedback would be greatly appreciated!

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Acked-by: John Youn 
Reviewed-by: Vardan Mikayelyan 
Signed-off-by: John Stultz 
---
v2: Rework goto logic suggested by Vardan, and add a comment
---
 drivers/usb/dwc2/hcd.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 911c3b3..b60307a 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3241,6 +3241,14 @@ static void dwc2_conn_id_status_change(struct 
work_struct *work)
 dwc2_is_host_mode(hsotg) ? "Host" :
 "Peripheral");
usleep_range(2, 4);
+   /*
+* Sometimes the initial GOTGCTRL read is wrong, so
+* check it again and jump to host mode if that was
+* the case.
+*/
+   gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+   if (!(gotgctl & GOTGCTL_CONID_B))
+   goto host;
if (++count > 250)
break;
}
@@ -3255,6 +3263,7 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
spin_unlock_irqrestore(>lock, flags);
dwc2_hsotg_core_connect(hsotg);
} else {
+host:
/* A-Device connector (Host Mode) */
dev_dbg(hsotg->dev, "connId A\n");
while (!dwc2_is_host_mode(hsotg)) {
-- 
2.7.4

[RFC][PATCH 5/5 v2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

[John Stultz]

From: Chen Yu 

The Hi6220's usb controller is limited in that it does not
support "Split Transactions", so it does not support communicating
with low-speed and full-speed devices behind a high-speed hub.

Thus it requires a quirk so that we can manually drop the usb
speed when low/full-speed are attached, and bump back to high
speed when they are removed.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
[jstultz: Reworked to simplify the patch, and made
 commit log to be more specific about the issue]
Signed-off-by: John Stultz 
---
v2:
* Fix build issue reported by kbuildbot
* Rework to avoid using new dts entry suggested by RobH
* Further tweaks from Chen Yu to try to address comments from
  John Youn
* Further simplified logic
v3:
* Reworked to adapt around changes that landed in 4.10-rc
---
 drivers/usb/dwc2/core.h   |  7 ++
 drivers/usb/dwc2/hcd.c| 60 +++
 drivers/usb/dwc2/params.c | 19 +++
 3 files changed, 86 insertions(+)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index eb2d628..4074752 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -444,6 +444,11 @@ enum dwc2_ep0_state {
  * in DWORDS with possible values from from
  * 16-32768 (default: 256, 256, 256, 256, 768,
  * 768, 768, 768, 0, 0, 0, 0, 0, 0, 0).
+ * @change_speed_quirk: Change speed configuration to DWC2_SPEED_PARAM_FULL
+ *  while full speed device connect. And change speed
+ *  back to DWC2_SPEED_PARAM_HIGH while device is gone.
+ * 0 - No (default)
+ * 1 - Yes
  *
  * The following parameters may be specified when starting the module. These
  * parameters define how the DWC_otg controller should be configured. A
@@ -516,6 +521,8 @@ struct dwc2_core_params {
u16 g_rx_fifo_size;
u16 g_np_tx_fifo_size;
u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
+
+   int change_speed_quirk;
 };
 
 /**
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 6e4ec8a..81997d2 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4876,6 +4876,61 @@ static void _dwc2_hcd_clear_tt_buffer_complete(struct 
usb_hcd *hcd,
spin_unlock_irqrestore(>lock, flags);
 }
 
+/*
+ * HPRT0_SPD_HIGH_SPEED: high speed
+ * HPRT0_SPD_FULL_SPEED: full speed
+ */
+static void dwc2_change_bus_speed(struct usb_hcd *hcd, int speed)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (hsotg->params.speed == speed)
+   return;
+
+   hsotg->params.speed = speed;
+   queue_work(hsotg->wq_otg, >wf_otg);
+}
+
+static void dwc2_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->params.change_speed_quirk)
+   return;
+
+   /*
+* On removal, set speed to default high-speed.
+*/
+   if (udev->parent && udev->parent->speed > USB_SPEED_UNKNOWN &&
+   udev->parent->speed < USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to default high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   }
+}
+
+static int dwc2_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->params.change_speed_quirk)
+   return 0;
+
+   if (udev->speed == USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   } else if ((udev->speed == USB_SPEED_FULL ||
+   udev->speed == USB_SPEED_LOW)) {
+   /*
+* Change speed setting to full-speed if there's
+* a full-speed or low-speed device plugged in.
+*/
+   dev_info(hsotg->dev, "Set speed to full-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_FULL_SPEED);
+   }
+
+   return 0;
+}
+
 static struct hc_driver dwc2_hc_driver = {
.description = "dwc2_hsotg",
.product_desc = "DWC OTG Controller",
@@ -5031,6 +5086,11 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
dev_warn(hsotg->dev, "can't set coherent DMA mask\n");
}
 
+   if (hsotg->params.change_speed_quirk) {

[RFC][PATCH 5/5 v2] usb: dwc2: Add a quirk to allow speed negotiation for Hisilicon Hi6220

[John Stultz]

From: Chen Yu 

The Hi6220's usb controller is limited in that it does not
support "Split Transactions", so it does not support communicating
with low-speed and full-speed devices behind a high-speed hub.

Thus it requires a quirk so that we can manually drop the usb
speed when low/full-speed are attached, and bump back to high
speed when they are removed.

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Signed-off-by: Chen Yu 
[jstultz: Reworked to simplify the patch, and made
 commit log to be more specific about the issue]
Signed-off-by: John Stultz 
---
v2:
* Fix build issue reported by kbuildbot
* Rework to avoid using new dts entry suggested by RobH
* Further tweaks from Chen Yu to try to address comments from
  John Youn
* Further simplified logic
v3:
* Reworked to adapt around changes that landed in 4.10-rc
---
 drivers/usb/dwc2/core.h   |  7 ++
 drivers/usb/dwc2/hcd.c| 60 +++
 drivers/usb/dwc2/params.c | 19 +++
 3 files changed, 86 insertions(+)

diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index eb2d628..4074752 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -444,6 +444,11 @@ enum dwc2_ep0_state {
  * in DWORDS with possible values from from
  * 16-32768 (default: 256, 256, 256, 256, 768,
  * 768, 768, 768, 0, 0, 0, 0, 0, 0, 0).
+ * @change_speed_quirk: Change speed configuration to DWC2_SPEED_PARAM_FULL
+ *  while full speed device connect. And change speed
+ *  back to DWC2_SPEED_PARAM_HIGH while device is gone.
+ * 0 - No (default)
+ * 1 - Yes
  *
  * The following parameters may be specified when starting the module. These
  * parameters define how the DWC_otg controller should be configured. A
@@ -516,6 +521,8 @@ struct dwc2_core_params {
u16 g_rx_fifo_size;
u16 g_np_tx_fifo_size;
u32 g_tx_fifo_size[MAX_EPS_CHANNELS];
+
+   int change_speed_quirk;
 };
 
 /**
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 6e4ec8a..81997d2 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -4876,6 +4876,61 @@ static void _dwc2_hcd_clear_tt_buffer_complete(struct 
usb_hcd *hcd,
spin_unlock_irqrestore(>lock, flags);
 }
 
+/*
+ * HPRT0_SPD_HIGH_SPEED: high speed
+ * HPRT0_SPD_FULL_SPEED: full speed
+ */
+static void dwc2_change_bus_speed(struct usb_hcd *hcd, int speed)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (hsotg->params.speed == speed)
+   return;
+
+   hsotg->params.speed = speed;
+   queue_work(hsotg->wq_otg, >wf_otg);
+}
+
+static void dwc2_free_dev(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->params.change_speed_quirk)
+   return;
+
+   /*
+* On removal, set speed to default high-speed.
+*/
+   if (udev->parent && udev->parent->speed > USB_SPEED_UNKNOWN &&
+   udev->parent->speed < USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to default high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   }
+}
+
+static int dwc2_reset_device(struct usb_hcd *hcd, struct usb_device *udev)
+{
+   struct dwc2_hsotg *hsotg = dwc2_hcd_to_hsotg(hcd);
+
+   if (!hsotg->params.change_speed_quirk)
+   return 0;
+
+   if (udev->speed == USB_SPEED_HIGH) {
+   dev_info(hsotg->dev, "Set speed to high-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_HIGH_SPEED);
+   } else if ((udev->speed == USB_SPEED_FULL ||
+   udev->speed == USB_SPEED_LOW)) {
+   /*
+* Change speed setting to full-speed if there's
+* a full-speed or low-speed device plugged in.
+*/
+   dev_info(hsotg->dev, "Set speed to full-speed\n");
+   dwc2_change_bus_speed(hcd, HPRT0_SPD_FULL_SPEED);
+   }
+
+   return 0;
+}
+
 static struct hc_driver dwc2_hc_driver = {
.description = "dwc2_hsotg",
.product_desc = "DWC OTG Controller",
@@ -5031,6 +5086,11 @@ int dwc2_hcd_init(struct dwc2_hsotg *hsotg, int irq)
dev_warn(hsotg->dev, "can't set coherent DMA mask\n");
}
 
+   if (hsotg->params.change_speed_quirk) {
+   dwc2_hc_driver.free_dev = dwc2_free_dev;
+   dwc2_hc_driver.reset_device = dwc2_reset_device;
+   }
+
hcd = usb_create_hcd(_hc_driver, hsotg->dev, dev_name(hsotg->dev));
if (!hcd)
goto error1;
diff --git a/drivers/usb/dwc2/params.c 

[RFC][PATCH 2/5 v2] usb: dwc2: Workaround case where GOTGCTL state is wrong

[John Stultz]

When removing a USB-A to USB-otg adapter cable, we get a change
status irq, and then in dwc2_conn_id_status_change, we
erroniously see the GOTGCTL_CONID_B flag set. This causes us to
get  stuck in the "while (!dwc2_is_device_mode(hsotg))" loop,
spitting out "Waiting for Peripheral Mode, Mode=Host" warnings
until it fails out many seconds later.

This patch works around the issue by re-reading the GOTGCTL
state to check if the GOTGCTL_CONID_B is still set and if not
restarting the change status logic.

I suspect this isn't the best solution, but it seems to work
well for me.

Feedback would be greatly appreciated!

Cc: Wei Xu 
Cc: Guodong Xu 
Cc: Amit Pundir 
Cc: Rob Herring 
Cc: John Youn 
Cc: Douglas Anderson 
Cc: Chen Yu 
Cc: Vardan Mikayelyan 
Cc: Kishon Vijay Abraham I 
Cc: Felipe Balbi 
Cc: Greg Kroah-Hartman 
Cc: linux-...@vger.kernel.org
Acked-by: John Youn 
Reviewed-by: Vardan Mikayelyan 
Signed-off-by: John Stultz 
---
v2: Rework goto logic suggested by Vardan, and add a comment
---
 drivers/usb/dwc2/hcd.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 911c3b3..b60307a 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -3241,6 +3241,14 @@ static void dwc2_conn_id_status_change(struct 
work_struct *work)
 dwc2_is_host_mode(hsotg) ? "Host" :
 "Peripheral");
usleep_range(2, 4);
+   /*
+* Sometimes the initial GOTGCTRL read is wrong, so
+* check it again and jump to host mode if that was
+* the case.
+*/
+   gotgctl = dwc2_readl(hsotg->regs + GOTGCTL);
+   if (!(gotgctl & GOTGCTL_CONID_B))
+   goto host;
if (++count > 250)
break;
}
@@ -3255,6 +3263,7 @@ static void dwc2_conn_id_status_change(struct work_struct 
*work)
spin_unlock_irqrestore(>lock, flags);
dwc2_hsotg_core_connect(hsotg);
} else {
+host:
/* A-Device connector (Host Mode) */
dev_dbg(hsotg->dev, "connId A\n");
while (!dwc2_is_host_mode(hsotg)) {
-- 
2.7.4

[PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

[John Stultz]

This patch adds CAP_GROUP and logic to allows a process to
migrate other tasks between cgroups.

In Android (where this feature originated), the ActivityManager
tracks various application states (TOP_APP, FOREGROUND,
BACKGROUND, SYSTEM, etc), and then as applications change
states, the SchedPolicy logic will migrate the application tasks
between different cgroups used to control the different
application states (for example, there is a background cpuset
cgroup which can limit background tasks to stay on one low-power
cpu, and the bg_non_interactive cpuctrl cgroup can then further
limit those background tasks to a small percentage of that one
cpu's cpu time).

However, for security reasons, Android doesn't want to make the
system_server (the process that runs the ActivityManager and
SchedPolicy logic), run as root. So in the Android common.git
kernel, they have some logic to allow cgroups to loosen their
permissions so CAP_SYS_NICE tasks can migrate other tasks between
cgroups.

I feel the approach taken there overloads CAP_SYS_NICE a bit much
for non-android environments. Efforts to re-use CAP_SYS_RESOURCE
for this purpose (which Android has since adopted) was also
stymied by concerns about risks from future cgroups that could be
considered "dangerous" by how they might change system semantics.

So to avoid overlapping usage, this patch adds a brand new
process capability flag (CAP_CGROUP), and uses it when checking
if a task can migrate other tasks between cgroups.

I've tested this with AOSP master (though its a bit hacked in as
I still need to properly get the selinux userspace bits aware of
the new capability bit) with selinux set to permissive and it
seems to be working well.

Thoughts and feedback would be appreciated!

(Note, I'm going on holiday break after today, so I may not
respond to feedback immediately, but I figured it would be
better to give folks the chance to review this rather then sit
it for two weeks. I'll resend after the new-year, addressing any
feedback I do get.)

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Christian Poetzsch 
Cc: Amit Pundir 
Cc: Dmitry Torokhov 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Cc: Andy Lutomirski 
Cc: linux-...@vger.kernel.org
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Eric Paris 
Cc: James Morris 
Cc: Jeff Vander Stoep 
Cc: linux-security-mod...@vger.kernel.org
Cc: seli...@tycho.nsa.gov
Signed-off-by: John Stultz 
---
v2: Renamed to just CAP_CGROUP_MIGRATE as reccomended by Tejun
v3: Switched to just using CAP_SYS_RESOURCE as suggested by Michael
v4: Send out properly folded down version of the patch. :P
v5: Switch back to CAP_CGROUP_MIGRATE due to concerns from Andy
v6: Rename to CAP_CGROUP, as it might be used for other purposes
in the future. Also added selinux mappings for the new cap.
---
 include/uapi/linux/capability.h | 5 -
 kernel/cgroup.c | 3 ++-
 security/selinux/include/classmap.h | 4 ++--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 49bc062..726f767 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -349,8 +349,11 @@ struct vfs_cap_data {
 
 #define CAP_AUDIT_READ 37
 
+/* Allow migration of other tasks between cgroups */
 
-#define CAP_LAST_CAP CAP_AUDIT_READ
+#define CAP_CGROUP 38
+
+#define CAP_LAST_CAP CAP_CGROUP
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2ee9ec3..8b42ae3 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2856,7 +2856,8 @@ static int cgroup_procs_write_permission(struct 
task_struct *task,
 */
if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
!uid_eq(cred->euid, tcred->uid) &&
-   !uid_eq(cred->euid, tcred->suid))
+   !uid_eq(cred->euid, tcred->suid) &&
+   !ns_capable(tcred->user_ns, CAP_CGROUP))
ret = -EACCES;
 
if (!ret && cgroup_on_dfl(dst_cgrp)) {
diff --git a/security/selinux/include/classmap.h 
b/security/selinux/include/classmap.h
index e2d4ad3a..ee8c1ed 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -22,9 +22,9 @@
"audit_control", "setfcap"
 
 #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
-   "wake_alarm", "block_suspend", "audit_read"
+ 

[PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

[John Stultz]

This patch adds CAP_GROUP and logic to allows a process to
migrate other tasks between cgroups.

In Android (where this feature originated), the ActivityManager
tracks various application states (TOP_APP, FOREGROUND,
BACKGROUND, SYSTEM, etc), and then as applications change
states, the SchedPolicy logic will migrate the application tasks
between different cgroups used to control the different
application states (for example, there is a background cpuset
cgroup which can limit background tasks to stay on one low-power
cpu, and the bg_non_interactive cpuctrl cgroup can then further
limit those background tasks to a small percentage of that one
cpu's cpu time).

However, for security reasons, Android doesn't want to make the
system_server (the process that runs the ActivityManager and
SchedPolicy logic), run as root. So in the Android common.git
kernel, they have some logic to allow cgroups to loosen their
permissions so CAP_SYS_NICE tasks can migrate other tasks between
cgroups.

I feel the approach taken there overloads CAP_SYS_NICE a bit much
for non-android environments. Efforts to re-use CAP_SYS_RESOURCE
for this purpose (which Android has since adopted) was also
stymied by concerns about risks from future cgroups that could be
considered "dangerous" by how they might change system semantics.

So to avoid overlapping usage, this patch adds a brand new
process capability flag (CAP_CGROUP), and uses it when checking
if a task can migrate other tasks between cgroups.

I've tested this with AOSP master (though its a bit hacked in as
I still need to properly get the selinux userspace bits aware of
the new capability bit) with selinux set to permissive and it
seems to be working well.

Thoughts and feedback would be appreciated!

(Note, I'm going on holiday break after today, so I may not
respond to feedback immediately, but I figured it would be
better to give folks the chance to review this rather then sit
it for two weeks. I'll resend after the new-year, addressing any
feedback I do get.)

Cc: Tejun Heo 
Cc: Li Zefan 
Cc: Jonathan Corbet 
Cc: cgro...@vger.kernel.org
Cc: Android Kernel Team 
Cc: Rom Lemarchand 
Cc: Colin Cross 
Cc: Dmitry Shmidt 
Cc: Todd Kjos 
Cc: Christian Poetzsch 
Cc: Amit Pundir 
Cc: Dmitry Torokhov 
Cc: Kees Cook 
Cc: Serge E. Hallyn 
Cc: Andy Lutomirski 
Cc: linux-...@vger.kernel.org
Cc: Paul Moore 
Cc: Stephen Smalley 
Cc: Eric Paris 
Cc: James Morris 
Cc: Jeff Vander Stoep 
Cc: linux-security-mod...@vger.kernel.org
Cc: seli...@tycho.nsa.gov
Signed-off-by: John Stultz 
---
v2: Renamed to just CAP_CGROUP_MIGRATE as reccomended by Tejun
v3: Switched to just using CAP_SYS_RESOURCE as suggested by Michael
v4: Send out properly folded down version of the patch. :P
v5: Switch back to CAP_CGROUP_MIGRATE due to concerns from Andy
v6: Rename to CAP_CGROUP, as it might be used for other purposes
in the future. Also added selinux mappings for the new cap.
---
 include/uapi/linux/capability.h | 5 -
 kernel/cgroup.c | 3 ++-
 security/selinux/include/classmap.h | 4 ++--
 3 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/capability.h b/include/uapi/linux/capability.h
index 49bc062..726f767 100644
--- a/include/uapi/linux/capability.h
+++ b/include/uapi/linux/capability.h
@@ -349,8 +349,11 @@ struct vfs_cap_data {
 
 #define CAP_AUDIT_READ 37
 
+/* Allow migration of other tasks between cgroups */
 
-#define CAP_LAST_CAP CAP_AUDIT_READ
+#define CAP_CGROUP 38
+
+#define CAP_LAST_CAP CAP_CGROUP
 
 #define cap_valid(x) ((x) >= 0 && (x) <= CAP_LAST_CAP)
 
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 2ee9ec3..8b42ae3 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -2856,7 +2856,8 @@ static int cgroup_procs_write_permission(struct 
task_struct *task,
 */
if (!uid_eq(cred->euid, GLOBAL_ROOT_UID) &&
!uid_eq(cred->euid, tcred->uid) &&
-   !uid_eq(cred->euid, tcred->suid))
+   !uid_eq(cred->euid, tcred->suid) &&
+   !ns_capable(tcred->user_ns, CAP_CGROUP))
ret = -EACCES;
 
if (!ret && cgroup_on_dfl(dst_cgrp)) {
diff --git a/security/selinux/include/classmap.h 
b/security/selinux/include/classmap.h
index e2d4ad3a..ee8c1ed 100644
--- a/security/selinux/include/classmap.h
+++ b/security/selinux/include/classmap.h
@@ -22,9 +22,9 @@
"audit_control", "setfcap"
 
 #define COMMON_CAP2_PERMS  "mac_override", "mac_admin", "syslog", \
-   "wake_alarm", "block_suspend", "audit_read"
+   "wake_alarm", "block_suspend", "audit_read", "cgroup"
 
-#if CAP_LAST_CAP > CAP_AUDIT_READ
+#if CAP_LAST_CAP > CAP_CGROUP
 #error New capability defined, please update COMMON_CAP2_PERMS.
 #endif
 
-- 
2.7.4

Re: [PATCH] x86/vm86: fix compilation warning on a unused variable

[Jérémy Lefaure]

On Mon, 12 Dec 2016 17:52:50 +0300
"Kirill A. Shutemov"  wrote:

> On Thu, Dec 08, 2016 at 01:25:37PM -0500, Jérémy Lefaure wrote:
> > On Thu, 8 Dec 2016 13:50:11 +0300
> > "Kirill A. Shutemov"  wrote:
> >   
> > > On Wed, Dec 07, 2016 at 11:38:33PM -0500, Jérémy Lefaure wrote:  
> > > > When CONFIG_TRANSPARENT_HUGEPAGE is disabled, split_huge_pmd is a no-op
> > > > stub. In such case, vma is unused and a compiler raises a warning:
> > > > 
> > > > arch/x86/kernel/vm86_32.c: In function ‘mark_screen_rdonly’:
> > > > arch/x86/kernel/vm86_32.c:180:26: warning: unused variable ‘vma’
> > > > [-Wunused-variable]
> > > >struct vm_area_struct *vma = find_vma(mm, 0xA);
> > > >  ^~~
> > > > Adding __maybe_unused in the vma declaration fixes this warning.
> > > 
> > > Hm. pmd_trans_huge() is zero if CONFIG_TRANSPARENT_HUGEPAGE is not set.
> > > Compiler should get rid of whole block of code under the 'if'.
> > > 
> > > Could you share your kernel config which triggers the warning?
> > > And what compiler do you use?
> > >   
> > 
> > After a `make allnoconfig`, I enable "Legacy VM86 support" and nothing
> > else. I tested with 2 compilers, gcc 4.9.2 (on debian jessie) and gcc
> > 6.2.1 (on archlinux).
> > 
> > Actually, the compiler does not raise warnings on complete build (`make
> > mrproper`, configuration and `make`) but only on partial build (`make
> > arch/x86/kernel/vm86_32.o` or `touch arch/x86/kernel/vm86_32.c &&
> > make`). So maybe it is a compiler issue ?
> > 
Sorry, forget about this part, it's false. I may have tested too
quickly and missed something.

> > The solution you propose in your other email (adding "(void)__vma;" in
> > the no-op split_huge_pmd) seems to fix the warnings on partial build.  
> 
> This doesn't make any sense, but this works too:
> 
I don't know why gcc raises a warning on that even if it is not used.
Anyway, I'm sure that the warning is reproducible. Both of your
solutions fix the issue.

> diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
> index e339717af265..63ddc598f5a9 100644
> --- a/arch/x86/kernel/vm86_32.c
> +++ b/arch/x86/kernel/vm86_32.c
> @@ -160,6 +160,7 @@ void save_v86_state(struct kernel_vm86_regs *regs, int 
> retval)
> 
>  static void mark_screen_rdonly(struct mm_struct *mm)
>  {
> +   struct vm_area_struct *vma;
> pgd_t *pgd;
> p4d_t *p4d;
> pud_t *pud;
> @@ -181,7 +182,7 @@ static void mark_screen_rdonly(struct mm_struct *mm)
> pmd = pmd_offset(pud, 0xA);
> 
> if (pmd_trans_huge(*pmd)) {
> -   struct vm_area_struct *vma = find_vma(mm, 0xA);
> +   vma = find_vma(mm, 0xA);
> split_huge_pmd(vma, pmd, 0xA);
> }
> if (pmd_none_or_clear_bad(pmd))

Re: [PATCH] x86/vm86: fix compilation warning on a unused variable

[Jérémy Lefaure]

On Mon, 12 Dec 2016 17:52:50 +0300
"Kirill A. Shutemov"  wrote:

> On Thu, Dec 08, 2016 at 01:25:37PM -0500, Jérémy Lefaure wrote:
> > On Thu, 8 Dec 2016 13:50:11 +0300
> > "Kirill A. Shutemov"  wrote:
> >   
> > > On Wed, Dec 07, 2016 at 11:38:33PM -0500, Jérémy Lefaure wrote:  
> > > > When CONFIG_TRANSPARENT_HUGEPAGE is disabled, split_huge_pmd is a no-op
> > > > stub. In such case, vma is unused and a compiler raises a warning:
> > > > 
> > > > arch/x86/kernel/vm86_32.c: In function ‘mark_screen_rdonly’:
> > > > arch/x86/kernel/vm86_32.c:180:26: warning: unused variable ‘vma’
> > > > [-Wunused-variable]
> > > >struct vm_area_struct *vma = find_vma(mm, 0xA);
> > > >  ^~~
> > > > Adding __maybe_unused in the vma declaration fixes this warning.
> > > 
> > > Hm. pmd_trans_huge() is zero if CONFIG_TRANSPARENT_HUGEPAGE is not set.
> > > Compiler should get rid of whole block of code under the 'if'.
> > > 
> > > Could you share your kernel config which triggers the warning?
> > > And what compiler do you use?
> > >   
> > 
> > After a `make allnoconfig`, I enable "Legacy VM86 support" and nothing
> > else. I tested with 2 compilers, gcc 4.9.2 (on debian jessie) and gcc
> > 6.2.1 (on archlinux).
> > 
> > Actually, the compiler does not raise warnings on complete build (`make
> > mrproper`, configuration and `make`) but only on partial build (`make
> > arch/x86/kernel/vm86_32.o` or `touch arch/x86/kernel/vm86_32.c &&
> > make`). So maybe it is a compiler issue ?
> > 
Sorry, forget about this part, it's false. I may have tested too
quickly and missed something.

> > The solution you propose in your other email (adding "(void)__vma;" in
> > the no-op split_huge_pmd) seems to fix the warnings on partial build.  
> 
> This doesn't make any sense, but this works too:
> 
I don't know why gcc raises a warning on that even if it is not used.
Anyway, I'm sure that the warning is reproducible. Both of your
solutions fix the issue.

> diff --git a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c
> index e339717af265..63ddc598f5a9 100644
> --- a/arch/x86/kernel/vm86_32.c
> +++ b/arch/x86/kernel/vm86_32.c
> @@ -160,6 +160,7 @@ void save_v86_state(struct kernel_vm86_regs *regs, int 
> retval)
> 
>  static void mark_screen_rdonly(struct mm_struct *mm)
>  {
> +   struct vm_area_struct *vma;
> pgd_t *pgd;
> p4d_t *p4d;
> pud_t *pud;
> @@ -181,7 +182,7 @@ static void mark_screen_rdonly(struct mm_struct *mm)
> pmd = pmd_offset(pud, 0xA);
> 
> if (pmd_trans_huge(*pmd)) {
> -   struct vm_area_struct *vma = find_vma(mm, 0xA);
> +   vma = find_vma(mm, 0xA);
> split_huge_pmd(vma, pmd, 0xA);
> }
> if (pmd_none_or_clear_bad(pmd))

Re: [RFC 10/10] kmod: add a sanity check on module loading

[Rusty Russell]

"Luis R. Rodriguez"  writes:
> On Thu, Dec 15, 2016 at 10:57:42AM +1030, Rusty Russell wrote:
>> "Luis R. Rodriguez"  writes:
>> > kmod has an optimization in place whereby if a some kernel code
>> > uses request_module() on a module already loaded we never bother
>> > userspace as the module already is loaded. This is not true for
>> > get_fs_type() though as it uses aliases.
>> 
>> Well, the obvious thing to do here is block kmod if we're currently
>> loading the same module.
>
> OK thanks, I've now added this, it sure helps. Test cases 0008 and 0009 
> require
> hammering on the test over and over to see a failure on vanilla kernels,
> an upper bound I found was about 150 times each test. Running test 0008
> 150 times with this enhancement you mentioned shaves off ~4 seconds.
> For test 0009 it shaves off ~16 seconds, but as I note below the alias support
> was needed as well.
>
>> Otherwise it has to do some weird spinning
>> thing in userspace anyway.
>
> Right, but note that the get_fs_type() tests would still fail given
> module.c was not alias-aware yet.

AFAICT the mistake here is that kmod is returning "done, OK" when the
module it is trying to load is already loading (but not finished
loading).  That's the root problem; it's an attempt at optimization by
kmod which goes awry.

Looking at the code in the kernel, we *already* get this right: block if
a module is still loading anyway.  Once it succeeds we return -EBUSY; if
it fails we'll proceed to try to load it again.

I don't understand what you're trying to fix with adding aliases
in-kernel?

> FWIW a few things did occur to me:
>
> a) list_add_rcu() is used so new modules get added first

Only after we're sure that there are no duplicates.

> b) find_module_all() returns the last module which was added as it traverses
>the module list

> BTW should find_module_all() use rcu to traverse?

Yes; the kallsyms code does this on Oops.  Not really a big issue in
practice, but a nice fix.

Thanks,
Rusty.

>
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -594,7 +594,7 @@ static struct module *find_module_all(const char *name, 
> size_t len,
>  
>   module_assert_mutex_or_preempt();
>  
> - list_for_each_entry(mod, , list) {
> + list_for_each_entry_rcu(mod, , list) {
>   if (!even_unformed && mod->state == MODULE_STATE_UNFORMED)
>   continue;
>   if (strlen(mod->name) == len && !memcmp(mod->name, name, len))
> @@ -3532,7 +3532,7 @@ static int add_unformed_module(struct module *mod)
>   goto out;
>   }
>   mod_update_bounds(mod);
> - list_add_rcu(>list, );
> + list_add_tail_rcu(>list, );
>   mod_tree_insert(mod);
>   err = 0;
>  

Re: [RFC 10/10] kmod: add a sanity check on module loading

[Rusty Russell]

"Luis R. Rodriguez"  writes:
> On Thu, Dec 15, 2016 at 10:57:42AM +1030, Rusty Russell wrote:
>> "Luis R. Rodriguez"  writes:
>> > kmod has an optimization in place whereby if a some kernel code
>> > uses request_module() on a module already loaded we never bother
>> > userspace as the module already is loaded. This is not true for
>> > get_fs_type() though as it uses aliases.
>> 
>> Well, the obvious thing to do here is block kmod if we're currently
>> loading the same module.
>
> OK thanks, I've now added this, it sure helps. Test cases 0008 and 0009 
> require
> hammering on the test over and over to see a failure on vanilla kernels,
> an upper bound I found was about 150 times each test. Running test 0008
> 150 times with this enhancement you mentioned shaves off ~4 seconds.
> For test 0009 it shaves off ~16 seconds, but as I note below the alias support
> was needed as well.
>
>> Otherwise it has to do some weird spinning
>> thing in userspace anyway.
>
> Right, but note that the get_fs_type() tests would still fail given
> module.c was not alias-aware yet.

AFAICT the mistake here is that kmod is returning "done, OK" when the
module it is trying to load is already loading (but not finished
loading).  That's the root problem; it's an attempt at optimization by
kmod which goes awry.

Looking at the code in the kernel, we *already* get this right: block if
a module is still loading anyway.  Once it succeeds we return -EBUSY; if
it fails we'll proceed to try to load it again.

I don't understand what you're trying to fix with adding aliases
in-kernel?

> FWIW a few things did occur to me:
>
> a) list_add_rcu() is used so new modules get added first

Only after we're sure that there are no duplicates.

> b) find_module_all() returns the last module which was added as it traverses
>the module list

> BTW should find_module_all() use rcu to traverse?

Yes; the kallsyms code does this on Oops.  Not really a big issue in
practice, but a nice fix.

Thanks,
Rusty.

>
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -594,7 +594,7 @@ static struct module *find_module_all(const char *name, 
> size_t len,
>  
>   module_assert_mutex_or_preempt();
>  
> - list_for_each_entry(mod, , list) {
> + list_for_each_entry_rcu(mod, , list) {
>   if (!even_unformed && mod->state == MODULE_STATE_UNFORMED)
>   continue;
>   if (strlen(mod->name) == len && !memcmp(mod->name, name, len))
> @@ -3532,7 +3532,7 @@ static int add_unformed_module(struct module *mod)
>   goto out;
>   }
>   mod_update_bounds(mod);
> - list_add_rcu(>list, );
> + list_add_tail_rcu(>list, );
>   mod_tree_insert(mod);
>   err = 0;
>  

Re: [GIT PULL] KVM fixes for 4.10 merge window

[Pan Xinhui]

在 2016/12/17 03:42, Linus Torvalds 写道:

On Fri, Dec 16, 2016 at 8:57 AM, Paolo Bonzini  wrote:


  git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus


This piece-of-shit branch has obviously never been even compile-tested:

  arch/x86/kernel/kvm.c: In function ‘__kvm_vcpu_is_preempted’:
  arch/x86/kernel/kvm.c:596:14: error: ‘struct kvm_steal_time’ has no
member named ‘preempted’


hi, Linus
oh, my bad also. I introduce this struct member and use it in same 
patch.
Better to separate tem into two patches. I make one fix patch below. sorry 
again.

Hi, Paolo
I have known where is th problem, I think if we can set this 
->preempted later after preempted_enable()
or just introduce something like write_guest_nosleep (per cpu memory section in 
guest, so there is no page_fault or any other cannot sleep problems)?

thanks
xinhui
-
From d4fa3ea0b8b6f3e5ff511604a4a6665d1cbb74c3 Mon Sep 17 00:00:00 2001
From: Pan Xinhui 
Date: Sat, 17 Dec 2016 02:56:33 -0500
Subject: [PATCH] kvm: fix compile issue

we revert commit 0b9f6c4615c993d2b552e0d2bd1ade49b56e5beb which calls
sleep function while preempt_disable on host part. But we remove struct
kvm_steal_time::preempted too. This casues compile problem as both guest
and host code use it.

Fix it by adding struct kvm_steal_time::preempted back.

Signed-off-by: Pan Xinhui 
---
 arch/x86/include/uapi/asm/kvm_para.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
b/arch/x86/include/uapi/asm/kvm_para.h
index 94dc8ca..1421a65 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -45,7 +45,9 @@ struct kvm_steal_time {
__u64 steal;
__u32 version;
__u32 flags;
-   __u32 pad[12];
+   __u8  preempted;
+   __u8  u8_pad[3];
+   __u32 pad[11];
 };
 
 #define KVM_STEAL_ALIGNMENT_BITS 5

--
2.4.11


where commit b94c3698b4b0 ("Revert "x86/kvm: Support the vCPU
preemption check"") removed the "preempted" field from struct
kvm_steal_time, but you left this in place:

  __visible bool __kvm_vcpu_is_preempted(int cpu)
  {
  struct kvm_steal_time *src = _cpu(steal_time, cpu);

  return !!src->preempted;
  }

And no, that is not a merge artifact in my tree (although that
function did come in from Ingo). That compile failure comes from your
very own branch.

Am I upset? You bet I am. Get your act together. You can't just
randomly revert things without checking the end result.

 Linus

Re: [GIT PULL] KVM fixes for 4.10 merge window

[Pan Xinhui]

在 2016/12/17 03:42, Linus Torvalds 写道:

On Fri, Dec 16, 2016 at 8:57 AM, Paolo Bonzini  wrote:


  git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus


This piece-of-shit branch has obviously never been even compile-tested:

  arch/x86/kernel/kvm.c: In function ‘__kvm_vcpu_is_preempted’:
  arch/x86/kernel/kvm.c:596:14: error: ‘struct kvm_steal_time’ has no
member named ‘preempted’


hi, Linus
oh, my bad also. I introduce this struct member and use it in same 
patch.
Better to separate tem into two patches. I make one fix patch below. sorry 
again.

Hi, Paolo
I have known where is th problem, I think if we can set this 
->preempted later after preempted_enable()
or just introduce something like write_guest_nosleep (per cpu memory section in 
guest, so there is no page_fault or any other cannot sleep problems)?

thanks
xinhui
-
From d4fa3ea0b8b6f3e5ff511604a4a6665d1cbb74c3 Mon Sep 17 00:00:00 2001
From: Pan Xinhui 
Date: Sat, 17 Dec 2016 02:56:33 -0500
Subject: [PATCH] kvm: fix compile issue

we revert commit 0b9f6c4615c993d2b552e0d2bd1ade49b56e5beb which calls
sleep function while preempt_disable on host part. But we remove struct
kvm_steal_time::preempted too. This casues compile problem as both guest
and host code use it.

Fix it by adding struct kvm_steal_time::preempted back.

Signed-off-by: Pan Xinhui 
---
 arch/x86/include/uapi/asm/kvm_para.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
b/arch/x86/include/uapi/asm/kvm_para.h
index 94dc8ca..1421a65 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -45,7 +45,9 @@ struct kvm_steal_time {
__u64 steal;
__u32 version;
__u32 flags;
-   __u32 pad[12];
+   __u8  preempted;
+   __u8  u8_pad[3];
+   __u32 pad[11];
 };
 
 #define KVM_STEAL_ALIGNMENT_BITS 5

--
2.4.11


where commit b94c3698b4b0 ("Revert "x86/kvm: Support the vCPU
preemption check"") removed the "preempted" field from struct
kvm_steal_time, but you left this in place:

  __visible bool __kvm_vcpu_is_preempted(int cpu)
  {
  struct kvm_steal_time *src = _cpu(steal_time, cpu);

  return !!src->preempted;
  }

And no, that is not a merge artifact in my tree (although that
function did come in from Ingo). That compile failure comes from your
very own branch.

Am I upset? You bet I am. Get your act together. You can't just
randomly revert things without checking the end result.

 Linus

Re: [PATCH] TOMOYO: use designated initializers

[Tetsuo Handa]

Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
> 
> Signed-off-by: Kees Cook 
> ---
>  security/tomoyo/file.c   | 12 ++--
>  security/tomoyo/tomoyo.c | 20 ++--
>  2 files changed, 16 insertions(+), 16 deletions(-)

Acked-by: Tetsuo Handa 

James, please apply to linux-security.git .

Re: [PATCH] TOMOYO: use designated initializers

[Tetsuo Handa]

Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
> 
> Signed-off-by: Kees Cook 
> ---
>  security/tomoyo/file.c   | 12 ++--
>  security/tomoyo/tomoyo.c | 20 ++--
>  2 files changed, 16 insertions(+), 16 deletions(-)

Acked-by: Tetsuo Handa 

James, please apply to linux-security.git .

Re: [PATCH 2/2] remoteproc: Remove firmware_loading_complete

[Sarangdhar Joshi]

On 12/16/2016 11:28 AM, Bjorn Andersson wrote:

On Fri 16 Dec 00:26 PST 2016, loic pallardy wrote:




On 12/16/2016 01:03 AM, Sarangdhar Joshi wrote:

rproc_del() waits on firmware_loading_complete in order to
make sure rproc_add() completed successfully before calling
rproc_shutdown().  However since rproc_add() will always be
called before rproc_del(), we do not need to wait on
firmware_loading_complete. Drop this completion variable
altogether.


Hi,

firmware_loading_complete is used to synchronize all operations on rproc
with parallel work launched by request_firmware_nowait.


We had a deadlock scenario in this code, where a call to rproc_boot()
would grab the rproc mutex and the request_firmware_nowait() callback
would wait on this lock before it would signal the completion that the
rproc_boot() was waiting for.

As the request_firmware_nowait() doesn't do anything other than handle
auto_boot and signal the completion - and there is an internal sleep
mechanism for handling concurrent request_firmware calls - I posted a
patch and dropped the rproc_boot() wait thing.


That's right. Should have added reference to commit
"e9b4f9efff5021 ("remoteproc: Drop wait in __rproc_boot()")"




rproc_add could be done and firmware loading still pending. In that case
rproc_del mustn't be called before end of the procedure.


You're right.

We might have an outstanding request_firmware_nowait() when we hit
rproc_del() and we might free the underlaying rproc context.

Holding a reference over the request_firmware_nowait() would solve this,
but would cause issues if we get a rproc_add() from the same driver
(e.g. after module unload/load) before the firmware timer has fired -
and released the resources.


The asynchronous work request_firmware_work_func() is protected by 
get_device()/put_device() on remoteproc device. So we are probably 
covered for remoteproc device. However, I agree that parent device will 
still be an issue.




This issue could be remedied by moving the rproc_delete_debug_dir() to
rproc_del() and aim for not having any objects exposed outside the
remoteproc core once rproc_del() returns.



If you decide to remove this synchronization you need either to modify rproc
boot sequence or to replace it by something else.



I agree.


I agree too. rproc_boot() calls for non auto_boot case anyway calls 
request_firmware(). So calling __request_firmware asynchronously for non 
auto_boot case seems redundant. I was planning to send a patch to  call 
rproc_add_virtio_devices() for auto_boot case only. I guess I'll need to 
take care of only auto_boot case for the current issue then.


Regards,
Sarang



Regards,
Bjorn




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH 2/2] remoteproc: Remove firmware_loading_complete

[Sarangdhar Joshi]

On 12/16/2016 11:28 AM, Bjorn Andersson wrote:

On Fri 16 Dec 00:26 PST 2016, loic pallardy wrote:




On 12/16/2016 01:03 AM, Sarangdhar Joshi wrote:

rproc_del() waits on firmware_loading_complete in order to
make sure rproc_add() completed successfully before calling
rproc_shutdown().  However since rproc_add() will always be
called before rproc_del(), we do not need to wait on
firmware_loading_complete. Drop this completion variable
altogether.


Hi,

firmware_loading_complete is used to synchronize all operations on rproc
with parallel work launched by request_firmware_nowait.


We had a deadlock scenario in this code, where a call to rproc_boot()
would grab the rproc mutex and the request_firmware_nowait() callback
would wait on this lock before it would signal the completion that the
rproc_boot() was waiting for.

As the request_firmware_nowait() doesn't do anything other than handle
auto_boot and signal the completion - and there is an internal sleep
mechanism for handling concurrent request_firmware calls - I posted a
patch and dropped the rproc_boot() wait thing.


That's right. Should have added reference to commit
"e9b4f9efff5021 ("remoteproc: Drop wait in __rproc_boot()")"




rproc_add could be done and firmware loading still pending. In that case
rproc_del mustn't be called before end of the procedure.


You're right.

We might have an outstanding request_firmware_nowait() when we hit
rproc_del() and we might free the underlaying rproc context.

Holding a reference over the request_firmware_nowait() would solve this,
but would cause issues if we get a rproc_add() from the same driver
(e.g. after module unload/load) before the firmware timer has fired -
and released the resources.


The asynchronous work request_firmware_work_func() is protected by 
get_device()/put_device() on remoteproc device. So we are probably 
covered for remoteproc device. However, I agree that parent device will 
still be an issue.




This issue could be remedied by moving the rproc_delete_debug_dir() to
rproc_del() and aim for not having any objects exposed outside the
remoteproc core once rproc_del() returns.



If you decide to remove this synchronization you need either to modify rproc
boot sequence or to replace it by something else.



I agree.


I agree too. rproc_boot() calls for non auto_boot case anyway calls 
request_firmware(). So calling __request_firmware asynchronously for non 
auto_boot case seems redundant. I was planning to send a patch to  call 
rproc_add_virtio_devices() for auto_boot case only. I guess I'll need to 
take care of only auto_boot case for the current issue then.


Regards,
Sarang



Regards,
Bjorn




--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] input: i8042-x86ia64io.h: Add Pegatron touchpad to noloop table

[Marcos Paulo de Souza]

Avoid AUX loopback in Pegatron C15B touchpad, so input subsystem is able
to recognize a synaptics touchpad in the AUX port.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=93791
(Touchpad is not detected on DNS 0801480 notebook (PEGATRON C15B))

Suggested-by: Dmitry Torokhov 
Signed-off-by: Marcos Paulo de Souza 
---
 drivers/input/serio/i8042-x86ia64io.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/input/serio/i8042-x86ia64io.h 
b/drivers/input/serio/i8042-x86ia64io.h
index ddd3132..1776dc6 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -211,6 +211,12 @@ static const struct dmi_system_id __initconst 
i8042_dmi_noloop_table[] = {
DMI_MATCH(DMI_PRODUCT_VERSION, "Rev 1"),
},
},
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "PEGATRON CORPORATION"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "C15B"),
+   },
+   },
{ }
 };
 
-- 
2.9.3

[PATCH] input: i8042-x86ia64io.h: Add Pegatron touchpad to noloop table

[Marcos Paulo de Souza]

Avoid AUX loopback in Pegatron C15B touchpad, so input subsystem is able
to recognize a synaptics touchpad in the AUX port.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=93791
(Touchpad is not detected on DNS 0801480 notebook (PEGATRON C15B))

Suggested-by: Dmitry Torokhov 
Signed-off-by: Marcos Paulo de Souza 
---
 drivers/input/serio/i8042-x86ia64io.h | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/input/serio/i8042-x86ia64io.h 
b/drivers/input/serio/i8042-x86ia64io.h
index ddd3132..1776dc6 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -211,6 +211,12 @@ static const struct dmi_system_id __initconst 
i8042_dmi_noloop_table[] = {
DMI_MATCH(DMI_PRODUCT_VERSION, "Rev 1"),
},
},
+   {
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "PEGATRON CORPORATION"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "C15B"),
+   },
+   },
{ }
 };
 
-- 
2.9.3

Re: [PATCH] ACPICA: use designated initializers

[Rafael J. Wysocki]

On Sat, Dec 17, 2016 at 2:04 AM, Kees Cook  wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
>
> Signed-off-by: Kees Cook 
> ---
>  drivers/acpi/acpica/hwxfsleep.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
> index f76e0eab32b8..25cd5c66e102 100644
> --- a/drivers/acpi/acpica/hwxfsleep.c
> +++ b/drivers/acpi/acpica/hwxfsleep.c
> @@ -70,11 +70,12 @@ static acpi_status acpi_hw_sleep_dispatch(u8 sleep_state, 
> u32 function_id);
>  /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE */
>
>  static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
> -   {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> -acpi_hw_extended_sleep},
> -   {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> -acpi_hw_extended_wake_prep},
> -   {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake), 
> acpi_hw_extended_wake}
> +   { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> + .extended_function = acpi_hw_extended_sleep },
> +   { .legacy_function = 
> ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> + .extended_function = acpi_hw_extended_wake_prep },
> +   { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
> + .extended_function = acpi_hw_extended_wake }
>  };
>
>  /*
> --

The problem here is like in the other patch sent earlier today.  If we
change that here, it will diverge from the upstream file it has been
generated from.

Thanks,
Rafael

Re: [PATCH] ACPICA: use designated initializers

[Rafael J. Wysocki]

On Sat, Dec 17, 2016 at 2:04 AM, Kees Cook  wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
>
> Signed-off-by: Kees Cook 
> ---
>  drivers/acpi/acpica/hwxfsleep.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
> index f76e0eab32b8..25cd5c66e102 100644
> --- a/drivers/acpi/acpica/hwxfsleep.c
> +++ b/drivers/acpi/acpica/hwxfsleep.c
> @@ -70,11 +70,12 @@ static acpi_status acpi_hw_sleep_dispatch(u8 sleep_state, 
> u32 function_id);
>  /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE */
>
>  static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
> -   {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> -acpi_hw_extended_sleep},
> -   {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> -acpi_hw_extended_wake_prep},
> -   {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake), 
> acpi_hw_extended_wake}
> +   { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
> + .extended_function = acpi_hw_extended_sleep },
> +   { .legacy_function = 
> ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
> + .extended_function = acpi_hw_extended_wake_prep },
> +   { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
> + .extended_function = acpi_hw_extended_wake }
>  };
>
>  /*
> --

The problem here is like in the other patch sent earlier today.  If we
change that here, it will diverge from the upstream file it has been
generated from.

Thanks,
Rafael

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

[George Spelvin]

> I already did this. Check my branch.

Do you think it should return "u32" (as you currently have it) or
"unsigned long"?  I thought the latter, since it doesn't cost any
more and makes more 

> I wonder if this could also lead to a similar aliasing
> with arch_get_random_int, since I'm pretty sure all rdrand-like
> instructions return native word size anyway.

Well, Intel's can return 16, 32 or 64 bits, and it makes a
small difference with reseed scheduling.

>> - Ted, Andy Lutorminski and I will try to figure out a construction of
>>   get_random_long() that we all like.

> And me, I hope... No need to make this exclusive.

Gaah, engage brain before fingers.  That was so obvious I didn't say
it, and the result came out sounding extremely rude.

A better (but longer) way to write it would be "I'm sorry that I, Ted,
and Andy are all arguing with you and each other about how to do this
and we can't finalize this part yet".

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

[George Spelvin]

> I already did this. Check my branch.

Do you think it should return "u32" (as you currently have it) or
"unsigned long"?  I thought the latter, since it doesn't cost any
more and makes more 

> I wonder if this could also lead to a similar aliasing
> with arch_get_random_int, since I'm pretty sure all rdrand-like
> instructions return native word size anyway.

Well, Intel's can return 16, 32 or 64 bits, and it makes a
small difference with reseed scheduling.

>> - Ted, Andy Lutorminski and I will try to figure out a construction of
>>   get_random_long() that we all like.

> And me, I hope... No need to make this exclusive.

Gaah, engage brain before fingers.  That was so obvious I didn't say
it, and the result came out sounding extremely rude.

A better (but longer) way to write it would be "I'm sorry that I, Ted,
and Andy are all arguing with you and each other about how to do this
and we can't finalize this part yet".

Re: [PATCH] acpi: Fix format string type mistakes

[Rafael J. Wysocki]

On Sat, Dec 17, 2016 at 12:04 AM, Kees Cook  wrote:
> On Fri, Dec 16, 2016 at 2:36 PM, Rafael J. Wysocki  wrote:
>> On Fri, Dec 16, 2016 at 10:51 PM, Kees Cook  wrote:
>>> From: Emese Revfy 
>>>
>>> This adds the missing __printf attribute which allows compile time
>>> format string checking (and will be used by the coming initify gcc
>>> plugin). Additionally, this fixes the warnings exposed by the attribute.
>>>
>>> Signed-off-by: Emese Revfy 
>>> [kees: split scsi/acpi, merged attr and fix, new commit messages]
>>> Signed-off-by: Kees Cook 
>>
>> This modifies code that we get from an external projiect (ACPICA) and
>> the bugs should be fixed in there in the first place.
>
> Who should get CCed?

Fortunately, the right people are in the CC list already. :-)

>> Moreover, I'm not sure if adding __printf in acpiosxf.h is a good idea.
>
> Why not?

Because it would cause that file to diverge from its upstream
counterpart which would be sort of a problem.

> This is going to be needed by the initify plugin to do
> correct detection of what's being passed around to functions...

I guess the question is what we will miss if we don't do that
specifically for ACPICA.

Thanks,
Rafael

Re: [PATCH] acpi: Fix format string type mistakes

[Rafael J. Wysocki]

On Sat, Dec 17, 2016 at 12:04 AM, Kees Cook  wrote:
> On Fri, Dec 16, 2016 at 2:36 PM, Rafael J. Wysocki  wrote:
>> On Fri, Dec 16, 2016 at 10:51 PM, Kees Cook  wrote:
>>> From: Emese Revfy 
>>>
>>> This adds the missing __printf attribute which allows compile time
>>> format string checking (and will be used by the coming initify gcc
>>> plugin). Additionally, this fixes the warnings exposed by the attribute.
>>>
>>> Signed-off-by: Emese Revfy 
>>> [kees: split scsi/acpi, merged attr and fix, new commit messages]
>>> Signed-off-by: Kees Cook 
>>
>> This modifies code that we get from an external projiect (ACPICA) and
>> the bugs should be fixed in there in the first place.
>
> Who should get CCed?

Fortunately, the right people are in the CC list already. :-)

>> Moreover, I'm not sure if adding __printf in acpiosxf.h is a good idea.
>
> Why not?

Because it would cause that file to diverge from its upstream
counterpart which would be sort of a problem.

> This is going to be needed by the initify plugin to do
> correct detection of what's being passed around to functions...

I guess the question is what we will miss if we don't do that
specifically for ACPICA.

Thanks,
Rafael

Re: [PATCH] apparmor: use designated initializers

[John Johansen]

On 12/16/2016 05:04 PM, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
> 
> Signed-off-by: Kees Cook 
Acked-by: John Johansen 

I'll pull this in to my tree for the pull request I will be sending in
a couple weeks.

> ---
>  security/apparmor/file.c | 4 ++--
>  security/apparmor/lsm.c  | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index 4d2af4b01033..608971ac6781 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -349,8 +349,8 @@ static inline bool xindex_is_subset(u32 link, u32 target)
>  int aa_path_link(struct aa_profile *profile, struct dentry *old_dentry,
>const struct path *new_dir, struct dentry *new_dentry)
>  {
> - struct path link = { new_dir->mnt, new_dentry };
> - struct path target = { new_dir->mnt, old_dentry };
> + struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
> + struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
>   struct path_cond cond = {
>   d_backing_inode(old_dentry)->i_uid,
>   d_backing_inode(old_dentry)->i_mode
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 41b8cb115801..83b2ab5c9d08 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -176,7 +176,7 @@ static int common_perm_dir_dentry(int op, const struct 
> path *dir,
> struct dentry *dentry, u32 mask,
> struct path_cond *cond)
>  {
> - struct path path = { dir->mnt, dentry };
> + struct path path = { .mnt = dir->mnt, .dentry = dentry };
>  
>   return common_perm(op, , mask, cond);
>  }
> @@ -306,8 +306,8 @@ static int apparmor_path_rename(const struct path 
> *old_dir, struct dentry *old_d
>  
>   profile = aa_current_profile();
>   if (!unconfined(profile)) {
> - struct path old_path = { old_dir->mnt, old_dentry };
> - struct path new_path = { new_dir->mnt, new_dentry };
> + struct path old_path = { .mnt = old_dir->mnt, .dentry = 
> old_dentry };
> + struct path new_path = { .mnt = new_dir->mnt, .dentry = 
> new_dentry };
>   struct path_cond cond = { d_backing_inode(old_dentry)->i_uid,
> d_backing_inode(old_dentry)->i_mode
>   };
> 

Re: [PATCH] apparmor: use designated initializers

[John Johansen]

On 12/16/2016 05:04 PM, Kees Cook wrote:
> Prepare to mark sensitive kernel structures for randomization by making
> sure they're using designated initializers. These were identified during
> allyesconfig builds of x86, arm, and arm64, with most initializer fixes
> extracted from grsecurity.
> 
> Signed-off-by: Kees Cook 
Acked-by: John Johansen 

I'll pull this in to my tree for the pull request I will be sending in
a couple weeks.

> ---
>  security/apparmor/file.c | 4 ++--
>  security/apparmor/lsm.c  | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/security/apparmor/file.c b/security/apparmor/file.c
> index 4d2af4b01033..608971ac6781 100644
> --- a/security/apparmor/file.c
> +++ b/security/apparmor/file.c
> @@ -349,8 +349,8 @@ static inline bool xindex_is_subset(u32 link, u32 target)
>  int aa_path_link(struct aa_profile *profile, struct dentry *old_dentry,
>const struct path *new_dir, struct dentry *new_dentry)
>  {
> - struct path link = { new_dir->mnt, new_dentry };
> - struct path target = { new_dir->mnt, old_dentry };
> + struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
> + struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
>   struct path_cond cond = {
>   d_backing_inode(old_dentry)->i_uid,
>   d_backing_inode(old_dentry)->i_mode
> diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
> index 41b8cb115801..83b2ab5c9d08 100644
> --- a/security/apparmor/lsm.c
> +++ b/security/apparmor/lsm.c
> @@ -176,7 +176,7 @@ static int common_perm_dir_dentry(int op, const struct 
> path *dir,
> struct dentry *dentry, u32 mask,
> struct path_cond *cond)
>  {
> - struct path path = { dir->mnt, dentry };
> + struct path path = { .mnt = dir->mnt, .dentry = dentry };
>  
>   return common_perm(op, , mask, cond);
>  }
> @@ -306,8 +306,8 @@ static int apparmor_path_rename(const struct path 
> *old_dir, struct dentry *old_d
>  
>   profile = aa_current_profile();
>   if (!unconfined(profile)) {
> - struct path old_path = { old_dir->mnt, old_dentry };
> - struct path new_path = { new_dir->mnt, new_dentry };
> + struct path old_path = { .mnt = old_dir->mnt, .dentry = 
> old_dentry };
> + struct path new_path = { .mnt = new_dir->mnt, .dentry = 
> new_dentry };
>   struct path_cond cond = { d_backing_inode(old_dentry)->i_uid,
> d_backing_inode(old_dentry)->i_mode
>   };
> 

Re: [GIT pull] x86/cache: Updates for 4.10

[Tony Luck]

On Tue, Dec 13, 2016 at 1:01 AM, Thomas Gleixner  wrote:
> On Mon, 12 Dec 2016, Linus Torvalds wrote:
>
>> On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner  wrote:
>> Ugh, this is some funky stuff. And it's entirely x86-specific, with a
>> rather odd special filesystem interface.
>
> Yes. The interface is odd, but the hardware interface of that CAT stuff is
> odd as well.
>
> We tried hard to come up with an abstraction, but that only allows rather
> simple partitioning, but no way of sharing and dealing with the per package
> nature of this mechanism.
>
> In the end we decided to expose the allocation bitmaps directly so all
> combinations of the hardware can be utilized.

Note that there are going to be more resources that can be controlled
using the same mechanism (PQR_ASSOC.CLOSID indexes into an
array of resource specific MSRs that specify how much of the resource
is available to the current process). Next one should be along fairly soon.
Keep an eye on chapter 17 in volume 3 of the SDM.

The code changes for this next resource involve new validation functions
(the resource isn't a cache, and the MSRs for it aren't bitmasks). But I think
it extends nicely.

-Tony

Re: [GIT pull] x86/cache: Updates for 4.10

[Tony Luck]

On Tue, Dec 13, 2016 at 1:01 AM, Thomas Gleixner  wrote:
> On Mon, 12 Dec 2016, Linus Torvalds wrote:
>
>> On Mon, Dec 12, 2016 at 1:53 AM, Thomas Gleixner  wrote:
>> Ugh, this is some funky stuff. And it's entirely x86-specific, with a
>> rather odd special filesystem interface.
>
> Yes. The interface is odd, but the hardware interface of that CAT stuff is
> odd as well.
>
> We tried hard to come up with an abstraction, but that only allows rather
> simple partitioning, but no way of sharing and dealing with the per package
> nature of this mechanism.
>
> In the end we decided to expose the allocation bitmaps directly so all
> combinations of the hardware can be utilized.

Note that there are going to be more resources that can be controlled
using the same mechanism (PQR_ASSOC.CLOSID indexes into an
array of resource specific MSRs that specify how much of the resource
is available to the current process). Next one should be along fairly soon.
Keep an eye on chapter 17 in volume 3 of the SDM.

The code changes for this next resource involve new validation functions
(the resource isn't a cache, and the MSRs for it aren't bitmasks). But I think
it extends nicely.

-Tony

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

[Jason A. Donenfeld]

On Sat, Dec 17, 2016 at 12:44 AM, George Spelvin
 wrote:
> Ths advice I'd give now is:
> - Implement
> unsigned long hsiphash(const void *data, size_t len, const unsigned long 
> key[2])
>   .. as SipHash on 64-bit (maybe SipHash-1-3, still being discussed) and
>   HalfSipHash on 32-bit.

I already did this. Check my branch.

> - Document when it may or may not be used carefully.

Good idea. I'll write up some extensive documentation about all of
this, detailing use cases and our various conclusions.

> - #define get_random_int (unsigned)get_random_long

That's a good idea, since ultimately the other just casts in the
return value. I wonder if this could also lead to a similar aliasing
with arch_get_random_int, since I'm pretty sure all rdrand-like
instructions return native word size anyway.

> - Ted, Andy Lutorminski and I will try to figure out a construction of
>   get_random_long() that we all like.

And me, I hope... No need to make this exclusive.

Jason

Re: [PATCH v5 1/4] siphash: add cryptographically secure PRF

[Jason A. Donenfeld]

On Sat, Dec 17, 2016 at 12:44 AM, George Spelvin
 wrote:
> Ths advice I'd give now is:
> - Implement
> unsigned long hsiphash(const void *data, size_t len, const unsigned long 
> key[2])
>   .. as SipHash on 64-bit (maybe SipHash-1-3, still being discussed) and
>   HalfSipHash on 32-bit.

I already did this. Check my branch.

> - Document when it may or may not be used carefully.

Good idea. I'll write up some extensive documentation about all of
this, detailing use cases and our various conclusions.

> - #define get_random_int (unsigned)get_random_long

That's a good idea, since ultimately the other just casts in the
return value. I wonder if this could also lead to a similar aliasing
with arch_get_random_int, since I'm pretty sure all rdrand-like
instructions return native word size anyway.

> - Ted, Andy Lutorminski and I will try to figure out a construction of
>   get_random_long() that we all like.

And me, I hope... No need to make this exclusive.

Jason

Re: [PATCH] platform/x86: fujitsu-laptop: set default trigger for radio LED to rfkill-any

[Jonathan Woithe]

On Fri, Dec 16, 2016 at 03:46:03PM +0100, Micha?? K??pie?? wrote:
> The "radio components indicator" LED present in Lifebook E734/E744/E754
> should be lit when any radio transmitter is enabled, so set its default
> trigger to rfkill-any.

This shouldn't cause any problems.  At the end of the day it's only the
default; if for some reason it's inappropriate for any systems we could do
an override.

Acked-by: Jonathan Woithe 

> Signed-off-by: Micha?? K??pie?? 
> ---
> Note: the rfkill-any trigger is currently only present in
> mac80211-next/master.
> 
>  drivers/platform/x86/fujitsu-laptop.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/platform/x86/fujitsu-laptop.c 
> b/drivers/platform/x86/fujitsu-laptop.c
> index 61f39ab..bfc0eb3 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -202,6 +202,7 @@ static void radio_led_set(struct led_classdev *cdev,
>  
>  static struct led_classdev radio_led = {
>   .name = "fujitsu::radio_led",
> + .default_trigger = "rfkill-any",
>   .brightness_get = radio_led_get,
>   .brightness_set = radio_led_set
>  };

Re: [PATCH] platform/x86: fujitsu-laptop: set default trigger for radio LED to rfkill-any

[Jonathan Woithe]

On Fri, Dec 16, 2016 at 03:46:03PM +0100, Micha?? K??pie?? wrote:
> The "radio components indicator" LED present in Lifebook E734/E744/E754
> should be lit when any radio transmitter is enabled, so set its default
> trigger to rfkill-any.

This shouldn't cause any problems.  At the end of the day it's only the
default; if for some reason it's inappropriate for any systems we could do
an override.

Acked-by: Jonathan Woithe 

> Signed-off-by: Micha?? K??pie?? 
> ---
> Note: the rfkill-any trigger is currently only present in
> mac80211-next/master.
> 
>  drivers/platform/x86/fujitsu-laptop.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/platform/x86/fujitsu-laptop.c 
> b/drivers/platform/x86/fujitsu-laptop.c
> index 61f39ab..bfc0eb3 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -202,6 +202,7 @@ static void radio_led_set(struct led_classdev *cdev,
>  
>  static struct led_classdev radio_led = {
>   .name = "fujitsu::radio_led",
> + .default_trigger = "rfkill-any",
>   .brightness_get = radio_led_get,
>   .brightness_set = radio_led_set
>  };

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

[Stephen Boyd]

On 12/15, Pierre-Louis Bossart wrote:
> I am not sure I understand this last comment.
> init.name is not a constant, it's made of the "pmc_plt_clk_" string
> concatenated with an id which directly maps to which hardware clock
> is registered.

That's all fine. We need globally unique strings for clk names in
the framework so things work.

>Clients use devm_clk_get() with a "pmc_plt_clk_"
> argument.

This is the problem. Clients should be calling clk_get() like:

clk_get(dev, "signal name in datasheet")

where the first argument is the device and the second argument is
some string that is meaningful to the device, not the system as a
whole. The way clkdev is intended is so that the dev argument's
dev_name() is combined with the con_id that matches some signale
name in the datasheet. This way when the same IP is put into some
other chip, the globally unique name doesn't need to change, just
the device name that's registered with the lookup. Obviously this
breaks down quite badly when dev_name() isn't stable. Is that
happening here?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [alsa-devel] [PATCH v6 1/3] clk: x86: Add Atom PMC platform clocks

[Stephen Boyd]

On 12/15, Pierre-Louis Bossart wrote:
> I am not sure I understand this last comment.
> init.name is not a constant, it's made of the "pmc_plt_clk_" string
> concatenated with an id which directly maps to which hardware clock
> is registered.

That's all fine. We need globally unique strings for clk names in
the framework so things work.

>Clients use devm_clk_get() with a "pmc_plt_clk_"
> argument.

This is the problem. Clients should be calling clk_get() like:

clk_get(dev, "signal name in datasheet")

where the first argument is the device and the second argument is
some string that is meaningful to the device, not the system as a
whole. The way clkdev is intended is so that the dev argument's
dev_name() is combined with the con_id that matches some signale
name in the datasheet. This way when the same IP is put into some
other chip, the globally unique name doesn't need to change, just
the device name that's registered with the lookup. Obviously this
breaks down quite badly when dev_name() isn't stable. Is that
happening here?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v6] soc: qcom: Add SoC info driver

[Stephen Boyd]

On 12/15, Imran Khan wrote:
> On 12/14/2016 5:56 AM, Stephen Boyd wrote:
> > On 12/12, Imran Khan wrote:
> >> The SoC info driver provides information such as Chip ID,
> >> Chip family, serial number and other such details about
> >> Qualcomm SoCs.
> > 
> > Yes but why do we care?
> >
> 
> We intend to expose some standard SoC attributes (like soc-id) of
> QCOM SoCs to user space, so that if needed the user space utilities
> (like antutu) can query such information using sysfs interface.   
> A further example can be a user space script (say Android's init.rc)
> which reads soc-id and does some gpio settings based on the soc-id.

Please include such information into the commit text.

> 
> >> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> >> index 18ec52f..c598cac 100644
> >> --- a/drivers/soc/qcom/smem.c
> >> +++ b/drivers/soc/qcom/smem.c
> >> @@ -85,6 +85,9 @@
> >>  /* Max number of processors/hosts in a system */
> >>  #define SMEM_HOST_COUNT   9
> >>  
> >> +
> >> +extern void qcom_socinfo_init(struct platform_device *pdev);
> > 
> > We can't put this into a header file?
> >
> 
> We can. In fact earlier I had put it in smem.h but since smem.h is public
> API for smem I removed it from there. As it was only a single function 
> I used this extern declaration. Please let me know if it is acceptable.
> If it is not acceptable I will create a socinfo.h and will put this 
> declaration 
> there.

I'm not sure we care about public vs. non-public APIs
intermingled in the same file. Did anyone ask for it to be moved
out of the header file? smem.h seems like a fine place to put.

> 
> 
> >> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> >> new file mode 100644
> >> index 000..57e23dfc
> >> --- /dev/null
> >> +++ b/drivers/soc/qcom/socinfo.c
> >> +
> >> +/* Hardware platform types */
> >> +static const char *const hw_platform[] = {
> >> +  [0] = "Unknown",
> >> +  [1] = "Surf",
> >> +  [2] = "FFA",
> >> +  [3] = "Fluid",
> >> +  [4] = "SVLTE_FFA",
> >> +  [5] = "SLVTE_SURF",
> >> +  [7] = "MDM_MTP_NO_DISPLAY",
> >> +  [8] = "MTP",
> >> +  [9] = "Liquid",
> >> +  [10] = "Dragon",
> >> +  [11] = "QRD",
> >> +  [13] = "HRD",
> >> +  [14] = "DTV",
> >> +  [21] = "RCM",
> >> +  [23] = "STP",
> >> +  [24] = "SBC",
> >> +};
> > 
> > These only make sense on qcom platforms. Other boards can reuse
> > the numbers here and have their own names for the platform field,
> > so it doesn't seem like a good idea to do this in the kernel.
> > 
> 
> Sorry could not understand this. Do you mean that we should only expose 
> the information that we can via generic soc_device_attribute. 
> This object is being used for hw_platform attribute which we are 
> explicitly creating in sysfs, so it should not conflict with other's
> implementation. 
> Or do you mean to just show the numbers and avoid the strings.
> I am using strings as I think in any case they will be more
> informative and also there are not many types/subtypes in any case.
> May be we can keep only those types/subtypes that are more frequent.
> 
> I may be completely wrong in understanding the comment here so could
> you kindly elaborate this a bit. 

I mean that the number 8 for example could mean MTP on qcom
platforms but to an ODM that isn't qcom (i.e. some phone
manufacturer) the number 8 could mean "wonderbolt 345". We really
have no way to control this number as it's completely arbitrary
what it means.

> >> +
> >> +static const char *const qrd_hw_platform_subtype[] = {
> >> +  [0] = "QRD",
> >> +  [1] = "SKUAA",
> >> +  [2] = "SKUF",
> >> +  [3] = "SKUAB",
> >> +  [5] = "SKUG",
> >> +  [6] = "INVALID",
> >> +};
> >> +
> >> +static const char *const hw_platform_subtype[] = {
> >> +  "Unknown", "charm", "strange", "strange_2a", "Invalid",
> >> +};
> > 
> > Same point here. Seems impossible to maintain this so please get
> > rid of it and just output raw numbers if anything.

And here the subtype becomes extremely complicated to parse.
charm, strange, etc. are really old platform subtypes that I
don't believe are used anymore but have stayed around in the code
for unknown reasons. The subtype field is very large and is
purely qcom specific.

> > 
> >> +
> >> +static const char *const pmic_model[] = {
> >> +  [0]  = "Unknown PMIC model",
> >> +  [13] = "PMIC model: PM8058",
> >> +  [14] = "PMIC model: PM8028",
> >> +  [15] = "PMIC model: PM8901",
> >> +  [16] = "PMIC model: PM8027",
> >> +  [17] = "PMIC model: ISL9519",
> >> +  [18] = "PMIC model: PM8921",
> >> +  [19] = "PMIC model: PM8018",
> >> +  [20] = "PMIC model: PM8015",
> >> +  [21] = "PMIC model: PM8014",
> >> +  [22] = "PMIC model: PM8821",
> >> +  [23] = "PMIC model: PM8038",
> >> +  [24] = "PMIC model: PM8922",
> >> +  [25] = "PMIC model: PM8917",
> > 
> > Why do we have "PMIC model:" in sysfs? Shouldn't that be evident
> > from the file name and shouldn't we strive for something more
> > machine readable? And do we expose all the different models 

Re: [PATCH v6] soc: qcom: Add SoC info driver

[Stephen Boyd]

On 12/15, Imran Khan wrote:
> On 12/14/2016 5:56 AM, Stephen Boyd wrote:
> > On 12/12, Imran Khan wrote:
> >> The SoC info driver provides information such as Chip ID,
> >> Chip family, serial number and other such details about
> >> Qualcomm SoCs.
> > 
> > Yes but why do we care?
> >
> 
> We intend to expose some standard SoC attributes (like soc-id) of
> QCOM SoCs to user space, so that if needed the user space utilities
> (like antutu) can query such information using sysfs interface.   
> A further example can be a user space script (say Android's init.rc)
> which reads soc-id and does some gpio settings based on the soc-id.

Please include such information into the commit text.

> 
> >> diff --git a/drivers/soc/qcom/smem.c b/drivers/soc/qcom/smem.c
> >> index 18ec52f..c598cac 100644
> >> --- a/drivers/soc/qcom/smem.c
> >> +++ b/drivers/soc/qcom/smem.c
> >> @@ -85,6 +85,9 @@
> >>  /* Max number of processors/hosts in a system */
> >>  #define SMEM_HOST_COUNT   9
> >>  
> >> +
> >> +extern void qcom_socinfo_init(struct platform_device *pdev);
> > 
> > We can't put this into a header file?
> >
> 
> We can. In fact earlier I had put it in smem.h but since smem.h is public
> API for smem I removed it from there. As it was only a single function 
> I used this extern declaration. Please let me know if it is acceptable.
> If it is not acceptable I will create a socinfo.h and will put this 
> declaration 
> there.

I'm not sure we care about public vs. non-public APIs
intermingled in the same file. Did anyone ask for it to be moved
out of the header file? smem.h seems like a fine place to put.

> 
> 
> >> diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
> >> new file mode 100644
> >> index 000..57e23dfc
> >> --- /dev/null
> >> +++ b/drivers/soc/qcom/socinfo.c
> >> +
> >> +/* Hardware platform types */
> >> +static const char *const hw_platform[] = {
> >> +  [0] = "Unknown",
> >> +  [1] = "Surf",
> >> +  [2] = "FFA",
> >> +  [3] = "Fluid",
> >> +  [4] = "SVLTE_FFA",
> >> +  [5] = "SLVTE_SURF",
> >> +  [7] = "MDM_MTP_NO_DISPLAY",
> >> +  [8] = "MTP",
> >> +  [9] = "Liquid",
> >> +  [10] = "Dragon",
> >> +  [11] = "QRD",
> >> +  [13] = "HRD",
> >> +  [14] = "DTV",
> >> +  [21] = "RCM",
> >> +  [23] = "STP",
> >> +  [24] = "SBC",
> >> +};
> > 
> > These only make sense on qcom platforms. Other boards can reuse
> > the numbers here and have their own names for the platform field,
> > so it doesn't seem like a good idea to do this in the kernel.
> > 
> 
> Sorry could not understand this. Do you mean that we should only expose 
> the information that we can via generic soc_device_attribute. 
> This object is being used for hw_platform attribute which we are 
> explicitly creating in sysfs, so it should not conflict with other's
> implementation. 
> Or do you mean to just show the numbers and avoid the strings.
> I am using strings as I think in any case they will be more
> informative and also there are not many types/subtypes in any case.
> May be we can keep only those types/subtypes that are more frequent.
> 
> I may be completely wrong in understanding the comment here so could
> you kindly elaborate this a bit. 

I mean that the number 8 for example could mean MTP on qcom
platforms but to an ODM that isn't qcom (i.e. some phone
manufacturer) the number 8 could mean "wonderbolt 345". We really
have no way to control this number as it's completely arbitrary
what it means.

> >> +
> >> +static const char *const qrd_hw_platform_subtype[] = {
> >> +  [0] = "QRD",
> >> +  [1] = "SKUAA",
> >> +  [2] = "SKUF",
> >> +  [3] = "SKUAB",
> >> +  [5] = "SKUG",
> >> +  [6] = "INVALID",
> >> +};
> >> +
> >> +static const char *const hw_platform_subtype[] = {
> >> +  "Unknown", "charm", "strange", "strange_2a", "Invalid",
> >> +};
> > 
> > Same point here. Seems impossible to maintain this so please get
> > rid of it and just output raw numbers if anything.

And here the subtype becomes extremely complicated to parse.
charm, strange, etc. are really old platform subtypes that I
don't believe are used anymore but have stayed around in the code
for unknown reasons. The subtype field is very large and is
purely qcom specific.

> > 
> >> +
> >> +static const char *const pmic_model[] = {
> >> +  [0]  = "Unknown PMIC model",
> >> +  [13] = "PMIC model: PM8058",
> >> +  [14] = "PMIC model: PM8028",
> >> +  [15] = "PMIC model: PM8901",
> >> +  [16] = "PMIC model: PM8027",
> >> +  [17] = "PMIC model: ISL9519",
> >> +  [18] = "PMIC model: PM8921",
> >> +  [19] = "PMIC model: PM8018",
> >> +  [20] = "PMIC model: PM8015",
> >> +  [21] = "PMIC model: PM8014",
> >> +  [22] = "PMIC model: PM8821",
> >> +  [23] = "PMIC model: PM8038",
> >> +  [24] = "PMIC model: PM8922",
> >> +  [25] = "PMIC model: PM8917",
> > 
> > Why do we have "PMIC model:" in sysfs? Shouldn't that be evident
> > from the file name and shouldn't we strive for something more
> > machine readable? And do we expose all the different models 

Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399

[Heiko Stuebner]

Am Freitag, 16. Dezember 2016, 14:57:01 CET schrieb Xing Zheng:
> Hi Heiko, Doug,
> 
> On 2016年12月16日 02:18, Heiko Stuebner wrote:
> > Am Donnerstag, 15. Dezember 2016, 08:34:09 CET schrieb Doug Anderson:
> >> I still need to digest all of the things that were added to this
> >> thread overnight, but nothing I've seen so far indicates that you need
> >> the post-gated clock.  AKA I still think you need to redo your patch
> >> 
> >> to replace:
> >>clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>,
> >>
> >> < SCLK_USBPHY0_480M_SRC>;
> >> 
> >> with:
> >>clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>,
> >>
> >>  <>;
> >> 
> >> Can you please comment on that?
> > 
> > Also, with the change, the ehci will keep the clock (and thus the phy)
> > always on. Does the phy-autosuspend even save anything now?
> > 
> > In any case, could we make the clock-names entry sound nicer than
> > usbphy0_480m please? bindings/usb/atmel-usb.txt calls its UTMI clock
> > simply "usb_clk", but something like "utmi" should also work.
> > While at it you could also fix up the other clock names to something like
> > "host" and "arbiter" or so?.
> > 
> > 
> > Heiko
> 
> The usbphy related clock tress like this:
> 
> 
> Actually, at drivers/phy/phy-rockchip-inno-usb2.c, we can only
> enable/disable the master gate via GRF is PHY_PLL, not UTMI_CLK.
> 
> And the naming style of the "hclk_host0" keep the name "hclk_host0" on
> the clcok tree diagram:
> 
> 
> Therefore, could we rename the clock name like this:
> 
> for usb_host0_ehci and usb_host0_ohci:
>  clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>,
>   < SCLK_U2PHY0>;
>  clock-names = "hclk_host0", "hclk_host0_arb",
>"sclk_u2phy0";
> 
> for usb_host1_ehci and usb_host1_ohci:
>  clocks = < HCLK_HOST1>, < HCLK_HOST1_ARB>,
>   < SCLK_U2PHY1>;
>  clock-names = "hclk_host1", "hclk_host1_arb",
>"sclk_u2phy1";
> 
> 
> BTW, the "arb" is an abbreviation for arbiter.

clock-naming wise, the clock names in devicetree bindings should always 
describe the clock in the context of the peripheral, not the hosts clock-tree.

So if the clock supplies the "arbiter" part, the clock-name should be called 
"arbiter". Same for "utmi" and the host clock that could be named "usbhost" or 
just "host" in the clock-names property.

Re: [PATCH 3/3] arm64: dts: rockchip: add clk-480m for ehci and ohci of rk3399

[Heiko Stuebner]

Am Freitag, 16. Dezember 2016, 14:57:01 CET schrieb Xing Zheng:
> Hi Heiko, Doug,
> 
> On 2016年12月16日 02:18, Heiko Stuebner wrote:
> > Am Donnerstag, 15. Dezember 2016, 08:34:09 CET schrieb Doug Anderson:
> >> I still need to digest all of the things that were added to this
> >> thread overnight, but nothing I've seen so far indicates that you need
> >> the post-gated clock.  AKA I still think you need to redo your patch
> >> 
> >> to replace:
> >>clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>,
> >>
> >> < SCLK_USBPHY0_480M_SRC>;
> >> 
> >> with:
> >>clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>,
> >>
> >>  <>;
> >> 
> >> Can you please comment on that?
> > 
> > Also, with the change, the ehci will keep the clock (and thus the phy)
> > always on. Does the phy-autosuspend even save anything now?
> > 
> > In any case, could we make the clock-names entry sound nicer than
> > usbphy0_480m please? bindings/usb/atmel-usb.txt calls its UTMI clock
> > simply "usb_clk", but something like "utmi" should also work.
> > While at it you could also fix up the other clock names to something like
> > "host" and "arbiter" or so?.
> > 
> > 
> > Heiko
> 
> The usbphy related clock tress like this:
> 
> 
> Actually, at drivers/phy/phy-rockchip-inno-usb2.c, we can only
> enable/disable the master gate via GRF is PHY_PLL, not UTMI_CLK.
> 
> And the naming style of the "hclk_host0" keep the name "hclk_host0" on
> the clcok tree diagram:
> 
> 
> Therefore, could we rename the clock name like this:
> 
> for usb_host0_ehci and usb_host0_ohci:
>  clocks = < HCLK_HOST0>, < HCLK_HOST0_ARB>,
>   < SCLK_U2PHY0>;
>  clock-names = "hclk_host0", "hclk_host0_arb",
>"sclk_u2phy0";
> 
> for usb_host1_ehci and usb_host1_ohci:
>  clocks = < HCLK_HOST1>, < HCLK_HOST1_ARB>,
>   < SCLK_U2PHY1>;
>  clock-names = "hclk_host1", "hclk_host1_arb",
>"sclk_u2phy1";
> 
> 
> BTW, the "arb" is an abbreviation for arbiter.

clock-naming wise, the clock names in devicetree bindings should always 
describe the clock in the context of the peripheral, not the hosts clock-tree.

So if the clock supplies the "arbiter" part, the clock-name should be called 
"arbiter". Same for "utmi" and the host clock that could be named "usbhost" or 
just "host" in the clock-names property.

Re: Questions on the task isolation patches

[yunhong jiang]

On Fri, 16 Dec 2016 16:00:48 -0500
Chris Metcalf  wrote:

> Sorry for the slow response - I have been busy with some other things.

Thanks for the reply.
> 
> On 12/6/2016 4:43 PM, yunhong jiang wrote:
> > On Fri, 2 Dec 2016 13:58:08 -0500
> > Chris Metcalf  wrote:
> >
> >> On 12/1/2016 5:28 PM, yunhong jiang wrote:
> >>> a) If the task isolation need prctl to mark itself as isolated,
> >>> possibly the vCPU thread can't achieve it. First, the vCPU thread
> >>> may need system service during OS booting time, also it's the
> >>> application, instead of the vCPU thread to decide if the vCPU
> >>> thread should be isolated. So possibly we need a mechanism so that
> >>> another process can set the vCPU thread's task isolation?
> >> These are good questions.  I think that the we would probably want
> >> to add a KVM mode that did the prctl() before transitioning back
> >> to the
> > Would prctl() when back to guest be too heavy?
> 
> It's a good question; it can be heavy.  But the design for task
> isolation is that the task isolated process is always running in
> userspace anyway.  If you are transitioning in and out of the guest
> or host kernels frequently, you probably should not be using task
> isolation, but just regular NOHZ_FULL.

As you pointed out late, the guest task isolation does not gurantee no guest VM
exit to host, although we hope we can achieve vmexit free situation in
future.

> 
> >> guest.  But then, in the same way that we currently allow another
> >> prctl() from a task-isolated userspace process, we'd probably need
> >> to
> > You mean currently in your patch we alraedy can do the prctl from
> > 3rd party process to task-isolate a userspace process? Sorry that I
> > didn't notice that part.
> 
> Sorry, I think I wasn't clear.  Normally when you are running task
> isolated and you enter the kernel, you will get a fatal signal.  The
> exception is if you call prctl itself (or exit), the kernel tolerates
> it without a signal, since obviously that's how you need to cleanly
> tell the kernel you are done with task isolation.
> 
> My point in the previous email was that we might need to similarly
> tolerate a guest exit without causing a fatal signal to the userspace
> process.  But as I think about it, that's probably not true; we
> probably would want to notify the guest kernel of the task isolation
> violation and have it kill the userspace process just as if it had
> entered the guest kernel.

Thanks for the clarification. It's clear now.

> 
> Perhaps the way to drive this is to have task isolation be triggered
> from the guest's prctl up to the host, so there's some kind of KVM
> exit to the host that indicates that the guest has a userspace
> process that wants to run task isolated, at which point qemu invokes
> task isolation on behalf of the guest then returns to the guest to
> set up its own virtualized task isolation.  It does get confusing!

Hmm, PV solution is always a choice on virtualization world.

> 

BTW, currently both the isolated CPU and task isolation requires the kernel
parameter to reserve CPUs in advance. Possibly we can extend it to be dynamic
like through sysfs in future, to avoid resource wast.

--jyh

Re: Questions on the task isolation patches

[yunhong jiang]

On Fri, 16 Dec 2016 16:00:48 -0500
Chris Metcalf  wrote:

> Sorry for the slow response - I have been busy with some other things.

Thanks for the reply.
> 
> On 12/6/2016 4:43 PM, yunhong jiang wrote:
> > On Fri, 2 Dec 2016 13:58:08 -0500
> > Chris Metcalf  wrote:
> >
> >> On 12/1/2016 5:28 PM, yunhong jiang wrote:
> >>> a) If the task isolation need prctl to mark itself as isolated,
> >>> possibly the vCPU thread can't achieve it. First, the vCPU thread
> >>> may need system service during OS booting time, also it's the
> >>> application, instead of the vCPU thread to decide if the vCPU
> >>> thread should be isolated. So possibly we need a mechanism so that
> >>> another process can set the vCPU thread's task isolation?
> >> These are good questions.  I think that the we would probably want
> >> to add a KVM mode that did the prctl() before transitioning back
> >> to the
> > Would prctl() when back to guest be too heavy?
> 
> It's a good question; it can be heavy.  But the design for task
> isolation is that the task isolated process is always running in
> userspace anyway.  If you are transitioning in and out of the guest
> or host kernels frequently, you probably should not be using task
> isolation, but just regular NOHZ_FULL.

As you pointed out late, the guest task isolation does not gurantee no guest VM
exit to host, although we hope we can achieve vmexit free situation in
future.

> 
> >> guest.  But then, in the same way that we currently allow another
> >> prctl() from a task-isolated userspace process, we'd probably need
> >> to
> > You mean currently in your patch we alraedy can do the prctl from
> > 3rd party process to task-isolate a userspace process? Sorry that I
> > didn't notice that part.
> 
> Sorry, I think I wasn't clear.  Normally when you are running task
> isolated and you enter the kernel, you will get a fatal signal.  The
> exception is if you call prctl itself (or exit), the kernel tolerates
> it without a signal, since obviously that's how you need to cleanly
> tell the kernel you are done with task isolation.
> 
> My point in the previous email was that we might need to similarly
> tolerate a guest exit without causing a fatal signal to the userspace
> process.  But as I think about it, that's probably not true; we
> probably would want to notify the guest kernel of the task isolation
> violation and have it kill the userspace process just as if it had
> entered the guest kernel.

Thanks for the clarification. It's clear now.

> 
> Perhaps the way to drive this is to have task isolation be triggered
> from the guest's prctl up to the host, so there's some kind of KVM
> exit to the host that indicates that the guest has a userspace
> process that wants to run task isolated, at which point qemu invokes
> task isolation on behalf of the guest then returns to the guest to
> set up its own virtualized task isolation.  It does get confusing!

Hmm, PV solution is always a choice on virtualization world.

> 

BTW, currently both the isolated CPU and task isolation requires the kernel
parameter to reserve CPUs in advance. Possibly we can extend it to be dynamic
like through sysfs in future, to avoid resource wast.

--jyh

[PATCH] reiserfs: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 fs/reiserfs/item_ops.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/fs/reiserfs/item_ops.c b/fs/reiserfs/item_ops.c
index aca73dd73906..e3c558d1b78c 100644
--- a/fs/reiserfs/item_ops.c
+++ b/fs/reiserfs/item_ops.c
@@ -724,18 +724,18 @@ static void errcatch_print_vi(struct virtual_item *vi)
 }
 
 static struct item_operations errcatch_ops = {
-   errcatch_bytes_number,
-   errcatch_decrement_key,
-   errcatch_is_left_mergeable,
-   errcatch_print_item,
-   errcatch_check_item,
-
-   errcatch_create_vi,
-   errcatch_check_left,
-   errcatch_check_right,
-   errcatch_part_size,
-   errcatch_unit_num,
-   errcatch_print_vi
+   .bytes_number = errcatch_bytes_number,
+   .decrement_key = errcatch_decrement_key,
+   .is_left_mergeable = errcatch_is_left_mergeable,
+   .print_item = errcatch_print_item,
+   .check_item = errcatch_check_item,
+
+   .create_vi = errcatch_create_vi,
+   .check_left = errcatch_check_left,
+   .check_right = errcatch_check_right,
+   .part_size = errcatch_part_size,
+   .unit_num = errcatch_unit_num,
+   .print_vi = errcatch_print_vi
 };
 
 #if ! (TYPE_STAT_DATA == 0 && TYPE_INDIRECT == 1 && TYPE_DIRECT == 2 && 
TYPE_DIRENTRY == 3)
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] solo6x10: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/media/pci/solo6x10/solo6x10-g723.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/solo6x10/solo6x10-g723.c 
b/drivers/media/pci/solo6x10/solo6x10-g723.c
index 6a35107aca25..36e93540bb49 100644
--- a/drivers/media/pci/solo6x10/solo6x10-g723.c
+++ b/drivers/media/pci/solo6x10/solo6x10-g723.c
@@ -350,7 +350,7 @@ static int solo_snd_pcm_init(struct solo_dev *solo_dev)
 
 int solo_g723_init(struct solo_dev *solo_dev)
 {
-   static struct snd_device_ops ops = { NULL };
+   static struct snd_device_ops ops = { };
struct snd_card *card;
struct snd_kcontrol_new kctl;
char name[32];
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] apparmor: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 security/apparmor/file.c | 4 ++--
 security/apparmor/lsm.c  | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index 4d2af4b01033..608971ac6781 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -349,8 +349,8 @@ static inline bool xindex_is_subset(u32 link, u32 target)
 int aa_path_link(struct aa_profile *profile, struct dentry *old_dentry,
 const struct path *new_dir, struct dentry *new_dentry)
 {
-   struct path link = { new_dir->mnt, new_dentry };
-   struct path target = { new_dir->mnt, old_dentry };
+   struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
+   struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
struct path_cond cond = {
d_backing_inode(old_dentry)->i_uid,
d_backing_inode(old_dentry)->i_mode
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 41b8cb115801..83b2ab5c9d08 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -176,7 +176,7 @@ static int common_perm_dir_dentry(int op, const struct path 
*dir,
  struct dentry *dentry, u32 mask,
  struct path_cond *cond)
 {
-   struct path path = { dir->mnt, dentry };
+   struct path path = { .mnt = dir->mnt, .dentry = dentry };
 
return common_perm(op, , mask, cond);
 }
@@ -306,8 +306,8 @@ static int apparmor_path_rename(const struct path *old_dir, 
struct dentry *old_d
 
profile = aa_current_profile();
if (!unconfined(profile)) {
-   struct path old_path = { old_dir->mnt, old_dentry };
-   struct path new_path = { new_dir->mnt, new_dentry };
+   struct path old_path = { .mnt = old_dir->mnt, .dentry = 
old_dentry };
+   struct path new_path = { .mnt = new_dir->mnt, .dentry = 
new_dentry };
struct path_cond cond = { d_backing_inode(old_dentry)->i_uid,
  d_backing_inode(old_dentry)->i_mode
};
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] hpsa: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/scsi/hpsa.h | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/hpsa.h b/drivers/scsi/hpsa.h
index 64e98295b707..bf6cdc106654 100644
--- a/drivers/scsi/hpsa.h
+++ b/drivers/scsi/hpsa.h
@@ -578,38 +578,38 @@ static unsigned long SA5_ioaccel_mode1_completed(struct 
ctlr_info *h, u8 q)
 }
 
 static struct access_method SA5_access = {
-   SA5_submit_command,
-   SA5_intr_mask,
-   SA5_intr_pending,
-   SA5_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_intr_mask,
+   .intr_pending = SA5_intr_pending,
+   .command_completed = SA5_completed,
 };
 
 static struct access_method SA5_ioaccel_mode1_access = {
-   SA5_submit_command,
-   SA5_performant_intr_mask,
-   SA5_ioaccel_mode1_intr_pending,
-   SA5_ioaccel_mode1_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .intr_pending = SA5_ioaccel_mode1_intr_pending,
+   .command_completed = SA5_ioaccel_mode1_completed,
 };
 
 static struct access_method SA5_ioaccel_mode2_access = {
-   SA5_submit_command_ioaccel2,
-   SA5_performant_intr_mask,
-   SA5_performant_intr_pending,
-   SA5_performant_completed,
+   .submit_command = SA5_submit_command_ioaccel2,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .intr_pending = SA5_performant_intr_pending,
+   .command_completed = SA5_performant_completed,
 };
 
 static struct access_method SA5_performant_access = {
-   SA5_submit_command,
-   SA5_performant_intr_mask,
-   SA5_performant_intr_pending,
-   SA5_performant_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .intr_pending = SA5_performant_intr_pending,
+   .command_completed = SA5_performant_completed,
 };
 
 static struct access_method SA5_performant_access_no_read = {
-   SA5_submit_command_no_read,
-   SA5_performant_intr_mask,
-   SA5_performant_intr_pending,
-   SA5_performant_completed,
+   .submit_command = SA5_submit_command_no_read,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .intr_pending = SA5_performant_intr_pending,
+   .command_completed = SA5_performant_completed,
 };
 
 struct board_type {
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] rbtree: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 include/linux/rbtree_augmented.h | 4 +++-
 lib/rbtree.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/linux/rbtree_augmented.h b/include/linux/rbtree_augmented.h
index d076183e49be..9702b6e183bc 100644
--- a/include/linux/rbtree_augmented.h
+++ b/include/linux/rbtree_augmented.h
@@ -90,7 +90,9 @@ rbname ## _rotate(struct rb_node *rb_old, struct rb_node 
*rb_new) \
old->rbaugmented = rbcompute(old);  \
 }  \
 rbstatic const struct rb_augment_callbacks rbname = {  \
-   rbname ## _propagate, rbname ## _copy, rbname ## _rotate\
+   .propagate = rbname ## _propagate,  \
+   .copy = rbname ## _copy,\
+   .rotate = rbname ## _rotate \
 };
 
 
diff --git a/lib/rbtree.c b/lib/rbtree.c
index 1f8b112a7c35..4ba2828a67c0 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -427,7 +427,9 @@ static inline void dummy_copy(struct rb_node *old, struct 
rb_node *new) {}
 static inline void dummy_rotate(struct rb_node *old, struct rb_node *new) {}
 
 static const struct rb_augment_callbacks dummy_callbacks = {
-   dummy_propagate, dummy_copy, dummy_rotate
+   .propagate = dummy_propagate,
+   .copy = dummy_copy,
+   .rotate = dummy_rotate
 };
 
 void rb_insert_color(struct rb_node *node, struct rb_root *root)
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] TOMOYO: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 security/tomoyo/file.c   | 12 ++--
 security/tomoyo/tomoyo.c | 20 ++--
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/security/tomoyo/file.c b/security/tomoyo/file.c
index 7041a580019e..223f21ffa632 100644
--- a/security/tomoyo/file.c
+++ b/security/tomoyo/file.c
@@ -692,7 +692,7 @@ int tomoyo_path_number_perm(const u8 type, const struct 
path *path,
 {
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path,
+   .path1 = { .mnt = path->mnt, .dentry = path->dentry },
};
int error = -ENOMEM;
struct tomoyo_path_info buf;
@@ -740,7 +740,7 @@ int tomoyo_check_open_permission(struct tomoyo_domain_info 
*domain,
struct tomoyo_path_info buf;
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path,
+   .path1 = { .mnt = path->mnt, .dentry = path->dentry },
};
int idx;
 
@@ -786,7 +786,7 @@ int tomoyo_path_perm(const u8 operation, const struct path 
*path, const char *ta
 {
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path,
+   .path1 = { .mnt = path->mnt, .dentry = path->dentry },
};
int error;
struct tomoyo_path_info buf;
@@ -843,7 +843,7 @@ int tomoyo_mkdev_perm(const u8 operation, const struct path 
*path,
 {
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path,
+   .path1 = { .mnt = path->mnt, .dentry = path->dentry },
};
int error = -ENOMEM;
struct tomoyo_path_info buf;
@@ -890,8 +890,8 @@ int tomoyo_path2_perm(const u8 operation, const struct path 
*path1,
struct tomoyo_path_info buf2;
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path1,
-   .path2 = *path2,
+   .path1 = { .mnt = path1->mnt, .dentry = path1->dentry },
+   .path2 = { .mnt = path2->mnt, .dentry = path2->dentry }
};
int idx;
 
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 75c998700190..b9569d497df2 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -165,7 +165,7 @@ static int tomoyo_path_truncate(const struct path *path)
  */
 static int tomoyo_path_unlink(const struct path *parent, struct dentry *dentry)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
return tomoyo_path_perm(TOMOYO_TYPE_UNLINK, , NULL);
 }
 
@@ -181,7 +181,7 @@ static int tomoyo_path_unlink(const struct path *parent, 
struct dentry *dentry)
 static int tomoyo_path_mkdir(const struct path *parent, struct dentry *dentry,
 umode_t mode)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
return tomoyo_path_number_perm(TOMOYO_TYPE_MKDIR, ,
   mode & S_IALLUGO);
 }
@@ -196,7 +196,7 @@ static int tomoyo_path_mkdir(const struct path *parent, 
struct dentry *dentry,
  */
 static int tomoyo_path_rmdir(const struct path *parent, struct dentry *dentry)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
return tomoyo_path_perm(TOMOYO_TYPE_RMDIR, , NULL);
 }
 
@@ -212,7 +212,7 @@ static int tomoyo_path_rmdir(const struct path *parent, 
struct dentry *dentry)
 static int tomoyo_path_symlink(const struct path *parent, struct dentry 
*dentry,
   const char *old_name)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
return tomoyo_path_perm(TOMOYO_TYPE_SYMLINK, , old_name);
 }
 
@@ -229,7 +229,7 @@ static int tomoyo_path_symlink(const struct path *parent, 
struct dentry *dentry,
 static int tomoyo_path_mknod(const struct path *parent, struct dentry *dentry,
 umode_t mode, unsigned int dev)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
int type = TOMOYO_TYPE_CREATE;
const unsigned int perm = mode & S_IALLUGO;
 
@@ -268,8 +268,8 @@ static int tomoyo_path_mknod(const struct path *parent, 
struct dentry *dentry,
 static int tomoyo_path_link(struct dentry *old_dentry, const struct path 
*new_dir,
struct dentry *new_dentry)
 {
-   struct path path1 = { new_dir->mnt, old_dentry };
-   

[PATCH] scsi/bfa: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/scsi/bfa/bfa_fcs.c   | 15 +++
 drivers/scsi/bfa/bfa_fcs_lport.c | 29 -
 drivers/scsi/bfa/bfa_modules.h   | 12 ++--
 3 files changed, 37 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/bfa/bfa_fcs.c b/drivers/scsi/bfa/bfa_fcs.c
index 1e7e139d71ea..f8f76501af90 100644
--- a/drivers/scsi/bfa/bfa_fcs.c
+++ b/drivers/scsi/bfa/bfa_fcs.c
@@ -39,10 +39,17 @@ struct bfa_fcs_mod_s {
 #define BFA_FCS_MODULE(_mod) { _mod ## _modinit, _mod ## _modexit }
 
 static struct bfa_fcs_mod_s fcs_modules[] = {
-   { bfa_fcs_port_attach, NULL, NULL },
-   { bfa_fcs_uf_attach, NULL, NULL },
-   { bfa_fcs_fabric_attach, bfa_fcs_fabric_modinit,
- bfa_fcs_fabric_modexit },
+   {
+   .attach = bfa_fcs_port_attach,
+   },
+   {
+   .attach = bfa_fcs_uf_attach,
+   },
+   {
+   .attach = bfa_fcs_fabric_attach,
+   .modinit = bfa_fcs_fabric_modinit,
+   .modexit = bfa_fcs_fabric_modexit
+   },
 };
 
 /*
diff --git a/drivers/scsi/bfa/bfa_fcs_lport.c b/drivers/scsi/bfa/bfa_fcs_lport.c
index 4ddda72f60e6..64860c730ec9 100644
--- a/drivers/scsi/bfa/bfa_fcs_lport.c
+++ b/drivers/scsi/bfa/bfa_fcs_lport.c
@@ -90,15 +90,26 @@ static struct {
void(*offline) (struct bfa_fcs_lport_s *port);
 } __port_action[] = {
{
-   bfa_fcs_lport_unknown_init, bfa_fcs_lport_unknown_online,
-   bfa_fcs_lport_unknown_offline}, {
-   bfa_fcs_lport_fab_init, bfa_fcs_lport_fab_online,
-   bfa_fcs_lport_fab_offline}, {
-   bfa_fcs_lport_n2n_init, bfa_fcs_lport_n2n_online,
-   bfa_fcs_lport_n2n_offline}, {
-   bfa_fcs_lport_loop_init, bfa_fcs_lport_loop_online,
-   bfa_fcs_lport_loop_offline},
-   };
+   .init = bfa_fcs_lport_unknown_init,
+   .online = bfa_fcs_lport_unknown_online,
+   .offline = bfa_fcs_lport_unknown_offline
+   },
+   {
+   .init = bfa_fcs_lport_fab_init,
+   .online = bfa_fcs_lport_fab_online,
+   .offline = bfa_fcs_lport_fab_offline
+   },
+   {
+   .init = bfa_fcs_lport_n2n_init,
+   .online = bfa_fcs_lport_n2n_online,
+   .offline = bfa_fcs_lport_n2n_offline
+   },
+   {
+   .init = bfa_fcs_lport_loop_init,
+   .online = bfa_fcs_lport_loop_online,
+   .offline = bfa_fcs_lport_loop_offline
+   },
+};
 
 /*
  *  fcs_port_sm FCS logical port state machine
diff --git a/drivers/scsi/bfa/bfa_modules.h b/drivers/scsi/bfa/bfa_modules.h
index 53135f21fa0e..640621b4c3da 100644
--- a/drivers/scsi/bfa/bfa_modules.h
+++ b/drivers/scsi/bfa/bfa_modules.h
@@ -79,12 +79,12 @@ enum {
\
extern struct bfa_module_s hal_mod_ ## __mod;   \
struct bfa_module_s hal_mod_ ## __mod = {   \
-   bfa_ ## __mod ## _meminfo,  \
-   bfa_ ## __mod ## _attach,   \
-   bfa_ ## __mod ## _detach,   \
-   bfa_ ## __mod ## _start,\
-   bfa_ ## __mod ## _stop, \
-   bfa_ ## __mod ## _iocdisable,   \
+   .meminfo = bfa_ ## __mod ## _meminfo,   \
+   .attach = bfa_ ## __mod ## _attach, \
+   .detach = bfa_ ## __mod ## _detach, \
+   .start = bfa_ ## __mod ## _start,   \
+   .stop = bfa_ ## __mod ## _stop, \
+   .iocdisable = bfa_ ## __mod ## _iocdisable, \
}
 
 #define BFA_CACHELINE_SZ   (256)
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] reiserfs: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 fs/reiserfs/item_ops.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/fs/reiserfs/item_ops.c b/fs/reiserfs/item_ops.c
index aca73dd73906..e3c558d1b78c 100644
--- a/fs/reiserfs/item_ops.c
+++ b/fs/reiserfs/item_ops.c
@@ -724,18 +724,18 @@ static void errcatch_print_vi(struct virtual_item *vi)
 }
 
 static struct item_operations errcatch_ops = {
-   errcatch_bytes_number,
-   errcatch_decrement_key,
-   errcatch_is_left_mergeable,
-   errcatch_print_item,
-   errcatch_check_item,
-
-   errcatch_create_vi,
-   errcatch_check_left,
-   errcatch_check_right,
-   errcatch_part_size,
-   errcatch_unit_num,
-   errcatch_print_vi
+   .bytes_number = errcatch_bytes_number,
+   .decrement_key = errcatch_decrement_key,
+   .is_left_mergeable = errcatch_is_left_mergeable,
+   .print_item = errcatch_print_item,
+   .check_item = errcatch_check_item,
+
+   .create_vi = errcatch_create_vi,
+   .check_left = errcatch_check_left,
+   .check_right = errcatch_check_right,
+   .part_size = errcatch_part_size,
+   .unit_num = errcatch_unit_num,
+   .print_vi = errcatch_print_vi
 };
 
 #if ! (TYPE_STAT_DATA == 0 && TYPE_INDIRECT == 1 && TYPE_DIRECT == 2 && 
TYPE_DIRENTRY == 3)
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] solo6x10: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/media/pci/solo6x10/solo6x10-g723.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/solo6x10/solo6x10-g723.c 
b/drivers/media/pci/solo6x10/solo6x10-g723.c
index 6a35107aca25..36e93540bb49 100644
--- a/drivers/media/pci/solo6x10/solo6x10-g723.c
+++ b/drivers/media/pci/solo6x10/solo6x10-g723.c
@@ -350,7 +350,7 @@ static int solo_snd_pcm_init(struct solo_dev *solo_dev)
 
 int solo_g723_init(struct solo_dev *solo_dev)
 {
-   static struct snd_device_ops ops = { NULL };
+   static struct snd_device_ops ops = { };
struct snd_card *card;
struct snd_kcontrol_new kctl;
char name[32];
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] apparmor: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 security/apparmor/file.c | 4 ++--
 security/apparmor/lsm.c  | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/security/apparmor/file.c b/security/apparmor/file.c
index 4d2af4b01033..608971ac6781 100644
--- a/security/apparmor/file.c
+++ b/security/apparmor/file.c
@@ -349,8 +349,8 @@ static inline bool xindex_is_subset(u32 link, u32 target)
 int aa_path_link(struct aa_profile *profile, struct dentry *old_dentry,
 const struct path *new_dir, struct dentry *new_dentry)
 {
-   struct path link = { new_dir->mnt, new_dentry };
-   struct path target = { new_dir->mnt, old_dentry };
+   struct path link = { .mnt = new_dir->mnt, .dentry = new_dentry };
+   struct path target = { .mnt = new_dir->mnt, .dentry = old_dentry };
struct path_cond cond = {
d_backing_inode(old_dentry)->i_uid,
d_backing_inode(old_dentry)->i_mode
diff --git a/security/apparmor/lsm.c b/security/apparmor/lsm.c
index 41b8cb115801..83b2ab5c9d08 100644
--- a/security/apparmor/lsm.c
+++ b/security/apparmor/lsm.c
@@ -176,7 +176,7 @@ static int common_perm_dir_dentry(int op, const struct path 
*dir,
  struct dentry *dentry, u32 mask,
  struct path_cond *cond)
 {
-   struct path path = { dir->mnt, dentry };
+   struct path path = { .mnt = dir->mnt, .dentry = dentry };
 
return common_perm(op, , mask, cond);
 }
@@ -306,8 +306,8 @@ static int apparmor_path_rename(const struct path *old_dir, 
struct dentry *old_d
 
profile = aa_current_profile();
if (!unconfined(profile)) {
-   struct path old_path = { old_dir->mnt, old_dentry };
-   struct path new_path = { new_dir->mnt, new_dentry };
+   struct path old_path = { .mnt = old_dir->mnt, .dentry = 
old_dentry };
+   struct path new_path = { .mnt = new_dir->mnt, .dentry = 
new_dentry };
struct path_cond cond = { d_backing_inode(old_dentry)->i_uid,
  d_backing_inode(old_dentry)->i_mode
};
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] hpsa: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/scsi/hpsa.h | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/scsi/hpsa.h b/drivers/scsi/hpsa.h
index 64e98295b707..bf6cdc106654 100644
--- a/drivers/scsi/hpsa.h
+++ b/drivers/scsi/hpsa.h
@@ -578,38 +578,38 @@ static unsigned long SA5_ioaccel_mode1_completed(struct 
ctlr_info *h, u8 q)
 }
 
 static struct access_method SA5_access = {
-   SA5_submit_command,
-   SA5_intr_mask,
-   SA5_intr_pending,
-   SA5_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_intr_mask,
+   .intr_pending = SA5_intr_pending,
+   .command_completed = SA5_completed,
 };
 
 static struct access_method SA5_ioaccel_mode1_access = {
-   SA5_submit_command,
-   SA5_performant_intr_mask,
-   SA5_ioaccel_mode1_intr_pending,
-   SA5_ioaccel_mode1_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .intr_pending = SA5_ioaccel_mode1_intr_pending,
+   .command_completed = SA5_ioaccel_mode1_completed,
 };
 
 static struct access_method SA5_ioaccel_mode2_access = {
-   SA5_submit_command_ioaccel2,
-   SA5_performant_intr_mask,
-   SA5_performant_intr_pending,
-   SA5_performant_completed,
+   .submit_command = SA5_submit_command_ioaccel2,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .intr_pending = SA5_performant_intr_pending,
+   .command_completed = SA5_performant_completed,
 };
 
 static struct access_method SA5_performant_access = {
-   SA5_submit_command,
-   SA5_performant_intr_mask,
-   SA5_performant_intr_pending,
-   SA5_performant_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .intr_pending = SA5_performant_intr_pending,
+   .command_completed = SA5_performant_completed,
 };
 
 static struct access_method SA5_performant_access_no_read = {
-   SA5_submit_command_no_read,
-   SA5_performant_intr_mask,
-   SA5_performant_intr_pending,
-   SA5_performant_completed,
+   .submit_command = SA5_submit_command_no_read,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .intr_pending = SA5_performant_intr_pending,
+   .command_completed = SA5_performant_completed,
 };
 
 struct board_type {
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] rbtree: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 include/linux/rbtree_augmented.h | 4 +++-
 lib/rbtree.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/linux/rbtree_augmented.h b/include/linux/rbtree_augmented.h
index d076183e49be..9702b6e183bc 100644
--- a/include/linux/rbtree_augmented.h
+++ b/include/linux/rbtree_augmented.h
@@ -90,7 +90,9 @@ rbname ## _rotate(struct rb_node *rb_old, struct rb_node 
*rb_new) \
old->rbaugmented = rbcompute(old);  \
 }  \
 rbstatic const struct rb_augment_callbacks rbname = {  \
-   rbname ## _propagate, rbname ## _copy, rbname ## _rotate\
+   .propagate = rbname ## _propagate,  \
+   .copy = rbname ## _copy,\
+   .rotate = rbname ## _rotate \
 };
 
 
diff --git a/lib/rbtree.c b/lib/rbtree.c
index 1f8b112a7c35..4ba2828a67c0 100644
--- a/lib/rbtree.c
+++ b/lib/rbtree.c
@@ -427,7 +427,9 @@ static inline void dummy_copy(struct rb_node *old, struct 
rb_node *new) {}
 static inline void dummy_rotate(struct rb_node *old, struct rb_node *new) {}
 
 static const struct rb_augment_callbacks dummy_callbacks = {
-   dummy_propagate, dummy_copy, dummy_rotate
+   .propagate = dummy_propagate,
+   .copy = dummy_copy,
+   .rotate = dummy_rotate
 };
 
 void rb_insert_color(struct rb_node *node, struct rb_root *root)
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] TOMOYO: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 security/tomoyo/file.c   | 12 ++--
 security/tomoyo/tomoyo.c | 20 ++--
 2 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/security/tomoyo/file.c b/security/tomoyo/file.c
index 7041a580019e..223f21ffa632 100644
--- a/security/tomoyo/file.c
+++ b/security/tomoyo/file.c
@@ -692,7 +692,7 @@ int tomoyo_path_number_perm(const u8 type, const struct 
path *path,
 {
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path,
+   .path1 = { .mnt = path->mnt, .dentry = path->dentry },
};
int error = -ENOMEM;
struct tomoyo_path_info buf;
@@ -740,7 +740,7 @@ int tomoyo_check_open_permission(struct tomoyo_domain_info 
*domain,
struct tomoyo_path_info buf;
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path,
+   .path1 = { .mnt = path->mnt, .dentry = path->dentry },
};
int idx;
 
@@ -786,7 +786,7 @@ int tomoyo_path_perm(const u8 operation, const struct path 
*path, const char *ta
 {
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path,
+   .path1 = { .mnt = path->mnt, .dentry = path->dentry },
};
int error;
struct tomoyo_path_info buf;
@@ -843,7 +843,7 @@ int tomoyo_mkdev_perm(const u8 operation, const struct path 
*path,
 {
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path,
+   .path1 = { .mnt = path->mnt, .dentry = path->dentry },
};
int error = -ENOMEM;
struct tomoyo_path_info buf;
@@ -890,8 +890,8 @@ int tomoyo_path2_perm(const u8 operation, const struct path 
*path1,
struct tomoyo_path_info buf2;
struct tomoyo_request_info r;
struct tomoyo_obj_info obj = {
-   .path1 = *path1,
-   .path2 = *path2,
+   .path1 = { .mnt = path1->mnt, .dentry = path1->dentry },
+   .path2 = { .mnt = path2->mnt, .dentry = path2->dentry }
};
int idx;
 
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 75c998700190..b9569d497df2 100644
--- a/security/tomoyo/tomoyo.c
+++ b/security/tomoyo/tomoyo.c
@@ -165,7 +165,7 @@ static int tomoyo_path_truncate(const struct path *path)
  */
 static int tomoyo_path_unlink(const struct path *parent, struct dentry *dentry)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
return tomoyo_path_perm(TOMOYO_TYPE_UNLINK, , NULL);
 }
 
@@ -181,7 +181,7 @@ static int tomoyo_path_unlink(const struct path *parent, 
struct dentry *dentry)
 static int tomoyo_path_mkdir(const struct path *parent, struct dentry *dentry,
 umode_t mode)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
return tomoyo_path_number_perm(TOMOYO_TYPE_MKDIR, ,
   mode & S_IALLUGO);
 }
@@ -196,7 +196,7 @@ static int tomoyo_path_mkdir(const struct path *parent, 
struct dentry *dentry,
  */
 static int tomoyo_path_rmdir(const struct path *parent, struct dentry *dentry)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
return tomoyo_path_perm(TOMOYO_TYPE_RMDIR, , NULL);
 }
 
@@ -212,7 +212,7 @@ static int tomoyo_path_rmdir(const struct path *parent, 
struct dentry *dentry)
 static int tomoyo_path_symlink(const struct path *parent, struct dentry 
*dentry,
   const char *old_name)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
return tomoyo_path_perm(TOMOYO_TYPE_SYMLINK, , old_name);
 }
 
@@ -229,7 +229,7 @@ static int tomoyo_path_symlink(const struct path *parent, 
struct dentry *dentry,
 static int tomoyo_path_mknod(const struct path *parent, struct dentry *dentry,
 umode_t mode, unsigned int dev)
 {
-   struct path path = { parent->mnt, dentry };
+   struct path path = { .mnt = parent->mnt, .dentry = dentry };
int type = TOMOYO_TYPE_CREATE;
const unsigned int perm = mode & S_IALLUGO;
 
@@ -268,8 +268,8 @@ static int tomoyo_path_mknod(const struct path *parent, 
struct dentry *dentry,
 static int tomoyo_path_link(struct dentry *old_dentry, const struct path 
*new_dir,
struct dentry *new_dentry)
 {
-   struct path path1 = { new_dir->mnt, old_dentry };
-   struct path path2 = { 

[PATCH] scsi/bfa: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/scsi/bfa/bfa_fcs.c   | 15 +++
 drivers/scsi/bfa/bfa_fcs_lport.c | 29 -
 drivers/scsi/bfa/bfa_modules.h   | 12 ++--
 3 files changed, 37 insertions(+), 19 deletions(-)

diff --git a/drivers/scsi/bfa/bfa_fcs.c b/drivers/scsi/bfa/bfa_fcs.c
index 1e7e139d71ea..f8f76501af90 100644
--- a/drivers/scsi/bfa/bfa_fcs.c
+++ b/drivers/scsi/bfa/bfa_fcs.c
@@ -39,10 +39,17 @@ struct bfa_fcs_mod_s {
 #define BFA_FCS_MODULE(_mod) { _mod ## _modinit, _mod ## _modexit }
 
 static struct bfa_fcs_mod_s fcs_modules[] = {
-   { bfa_fcs_port_attach, NULL, NULL },
-   { bfa_fcs_uf_attach, NULL, NULL },
-   { bfa_fcs_fabric_attach, bfa_fcs_fabric_modinit,
- bfa_fcs_fabric_modexit },
+   {
+   .attach = bfa_fcs_port_attach,
+   },
+   {
+   .attach = bfa_fcs_uf_attach,
+   },
+   {
+   .attach = bfa_fcs_fabric_attach,
+   .modinit = bfa_fcs_fabric_modinit,
+   .modexit = bfa_fcs_fabric_modexit
+   },
 };
 
 /*
diff --git a/drivers/scsi/bfa/bfa_fcs_lport.c b/drivers/scsi/bfa/bfa_fcs_lport.c
index 4ddda72f60e6..64860c730ec9 100644
--- a/drivers/scsi/bfa/bfa_fcs_lport.c
+++ b/drivers/scsi/bfa/bfa_fcs_lport.c
@@ -90,15 +90,26 @@ static struct {
void(*offline) (struct bfa_fcs_lport_s *port);
 } __port_action[] = {
{
-   bfa_fcs_lport_unknown_init, bfa_fcs_lport_unknown_online,
-   bfa_fcs_lport_unknown_offline}, {
-   bfa_fcs_lport_fab_init, bfa_fcs_lport_fab_online,
-   bfa_fcs_lport_fab_offline}, {
-   bfa_fcs_lport_n2n_init, bfa_fcs_lport_n2n_online,
-   bfa_fcs_lport_n2n_offline}, {
-   bfa_fcs_lport_loop_init, bfa_fcs_lport_loop_online,
-   bfa_fcs_lport_loop_offline},
-   };
+   .init = bfa_fcs_lport_unknown_init,
+   .online = bfa_fcs_lport_unknown_online,
+   .offline = bfa_fcs_lport_unknown_offline
+   },
+   {
+   .init = bfa_fcs_lport_fab_init,
+   .online = bfa_fcs_lport_fab_online,
+   .offline = bfa_fcs_lport_fab_offline
+   },
+   {
+   .init = bfa_fcs_lport_n2n_init,
+   .online = bfa_fcs_lport_n2n_online,
+   .offline = bfa_fcs_lport_n2n_offline
+   },
+   {
+   .init = bfa_fcs_lport_loop_init,
+   .online = bfa_fcs_lport_loop_online,
+   .offline = bfa_fcs_lport_loop_offline
+   },
+};
 
 /*
  *  fcs_port_sm FCS logical port state machine
diff --git a/drivers/scsi/bfa/bfa_modules.h b/drivers/scsi/bfa/bfa_modules.h
index 53135f21fa0e..640621b4c3da 100644
--- a/drivers/scsi/bfa/bfa_modules.h
+++ b/drivers/scsi/bfa/bfa_modules.h
@@ -79,12 +79,12 @@ enum {
\
extern struct bfa_module_s hal_mod_ ## __mod;   \
struct bfa_module_s hal_mod_ ## __mod = {   \
-   bfa_ ## __mod ## _meminfo,  \
-   bfa_ ## __mod ## _attach,   \
-   bfa_ ## __mod ## _detach,   \
-   bfa_ ## __mod ## _start,\
-   bfa_ ## __mod ## _stop, \
-   bfa_ ## __mod ## _iocdisable,   \
+   .meminfo = bfa_ ## __mod ## _meminfo,   \
+   .attach = bfa_ ## __mod ## _attach, \
+   .detach = bfa_ ## __mod ## _detach, \
+   .start = bfa_ ## __mod ## _start,   \
+   .stop = bfa_ ## __mod ## _stop, \
+   .iocdisable = bfa_ ## __mod ## _iocdisable, \
}
 
 #define BFA_CACHELINE_SZ   (256)
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] drm/vmwgfx: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
index 170b61be1e4e..fec7348cea2c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
@@ -164,9 +164,9 @@ static void vmw_gmrid_man_debug(struct ttm_mem_type_manager 
*man,
 }
 
 const struct ttm_mem_type_manager_func vmw_gmrid_manager_func = {
-   vmw_gmrid_man_init,
-   vmw_gmrid_man_takedown,
-   vmw_gmrid_man_get_node,
-   vmw_gmrid_man_put_node,
-   vmw_gmrid_man_debug
+   .init = vmw_gmrid_man_init,
+   .takedown = vmw_gmrid_man_takedown,
+   .get_node = vmw_gmrid_man_get_node,
+   .put_node = vmw_gmrid_man_put_node,
+   .debug = vmw_gmrid_man_debug
 };
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] net/x25: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 net/x25/sysctl_net_x25.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/x25/sysctl_net_x25.c b/net/x25/sysctl_net_x25.c
index 43239527a205..a06dfe143c67 100644
--- a/net/x25/sysctl_net_x25.c
+++ b/net/x25/sysctl_net_x25.c
@@ -70,7 +70,7 @@ static struct ctl_table x25_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
-   { 0, },
+   { },
 };
 
 void __init x25_register_sysctl(void)
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] drm/nouveau: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index a6dbe8258040..ec4668a41e01 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -107,10 +107,10 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
 }
 
 const struct ttm_mem_type_manager_func nouveau_vram_manager = {
-   nouveau_vram_manager_init,
-   nouveau_vram_manager_fini,
-   nouveau_vram_manager_new,
-   nouveau_vram_manager_del,
+   .init = nouveau_vram_manager_init,
+   .takedown = nouveau_vram_manager_fini,
+   .get_node = nouveau_vram_manager_new,
+   .put_node = nouveau_vram_manager_del,
 };
 
 static int
@@ -184,11 +184,11 @@ nouveau_gart_manager_debug(struct ttm_mem_type_manager 
*man, const char *prefix)
 }
 
 const struct ttm_mem_type_manager_func nouveau_gart_manager = {
-   nouveau_gart_manager_init,
-   nouveau_gart_manager_fini,
-   nouveau_gart_manager_new,
-   nouveau_gart_manager_del,
-   nouveau_gart_manager_debug
+   .init = nouveau_gart_manager_init,
+   .takedown = nouveau_gart_manager_fini,
+   .get_node = nouveau_gart_manager_new,
+   .put_node = nouveau_gart_manager_del,
+   .debug = nouveau_gart_manager_debug
 };
 
 /*XXX*/
@@ -257,11 +257,11 @@ nv04_gart_manager_debug(struct ttm_mem_type_manager *man, 
const char *prefix)
 }
 
 const struct ttm_mem_type_manager_func nv04_gart_manager = {
-   nv04_gart_manager_init,
-   nv04_gart_manager_fini,
-   nv04_gart_manager_new,
-   nv04_gart_manager_del,
-   nv04_gart_manager_debug
+   .init = nv04_gart_manager_init,
+   .takedown = nv04_gart_manager_fini,
+   .get_node = nv04_gart_manager_new,
+   .put_node = nv04_gart_manager_del,
+   .debug = nv04_gart_manager_debug
 };
 
 int
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] cciss: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/block/cciss.h | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/block/cciss.h b/drivers/block/cciss.h
index 7fda30e4a241..428766d1ce80 100644
--- a/drivers/block/cciss.h
+++ b/drivers/block/cciss.h
@@ -402,27 +402,27 @@ static bool SA5_performant_intr_pending(ctlr_info_t *h)
 }
 
 static struct access_method SA5_access = {
-   SA5_submit_command,
-   SA5_intr_mask,
-   SA5_fifo_full,
-   SA5_intr_pending,
-   SA5_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_intr_mask,
+   .fifo_full = SA5_fifo_full,
+   .intr_pending = SA5_intr_pending,
+   .command_completed = SA5_completed,
 };
 
 static struct access_method SA5B_access = {
-SA5_submit_command,
-SA5B_intr_mask,
-SA5_fifo_full,
-SA5B_intr_pending,
-SA5_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5B_intr_mask,
+   .fifo_full = SA5_fifo_full,
+   .intr_pending = SA5B_intr_pending,
+   .command_completed = SA5_completed,
 };
 
 static struct access_method SA5_performant_access = {
-   SA5_submit_command,
-   SA5_performant_intr_mask,
-   SA5_fifo_full,
-   SA5_performant_intr_pending,
-   SA5_performant_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .fifo_full = SA5_fifo_full,
+   .intr_pending = SA5_performant_intr_pending,
+   .command_completed = SA5_performant_completed,
 };
 
 struct board_type {
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] RDMA/nes: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/infiniband/hw/nes/nes_cm.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/infiniband/hw/nes/nes_cm.c 
b/drivers/infiniband/hw/nes/nes_cm.c
index 8e703479e7ce..fb983df7c157 100644
--- a/drivers/infiniband/hw/nes/nes_cm.c
+++ b/drivers/infiniband/hw/nes/nes_cm.c
@@ -135,17 +135,17 @@ static void record_ird_ord(struct nes_cm_node *, u16, 
u16);
 /* instance of function pointers for client API */
 /* set address of this instance to cm_core->cm_ops at cm_core alloc */
 static const struct nes_cm_ops nes_cm_api = {
-   mini_cm_accelerated,
-   mini_cm_listen,
-   mini_cm_del_listen,
-   mini_cm_connect,
-   mini_cm_close,
-   mini_cm_accept,
-   mini_cm_reject,
-   mini_cm_recv_pkt,
-   mini_cm_dealloc_core,
-   mini_cm_get,
-   mini_cm_set
+   .accelerated = mini_cm_accelerated,
+   .listen = mini_cm_listen,
+   .stop_listener = mini_cm_del_listen,
+   .connect = mini_cm_connect,
+   .close = mini_cm_close,
+   .accept = mini_cm_accept,
+   .reject = mini_cm_reject,
+   .recv_pkt = mini_cm_recv_pkt,
+   .destroy_cm_core = mini_cm_dealloc_core,
+   .get = mini_cm_get,
+   .set = mini_cm_set
 };
 
 static struct nes_cm_core *g_cm_core;
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] x86/floppy: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 arch/x86/include/asm/floppy.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h
index 1c7eefe32502..d0e4702883b9 100644
--- a/arch/x86/include/asm/floppy.h
+++ b/arch/x86/include/asm/floppy.h
@@ -229,18 +229,18 @@ static struct fd_routine_l {
int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
 } fd_routine[] = {
{
-   request_dma,
-   free_dma,
-   get_dma_residue,
-   dma_mem_alloc,
-   hard_dma_setup
+   ._request_dma = request_dma,
+   ._free_dma = free_dma,
+   ._get_dma_residue = get_dma_residue,
+   ._dma_mem_alloc = dma_mem_alloc,
+   ._dma_setup = hard_dma_setup
},
{
-   vdma_request_dma,
-   vdma_nop,
-   vdma_get_dma_residue,
-   vdma_mem_alloc,
-   vdma_dma_setup
+   ._request_dma = vdma_request_dma,
+   ._free_dma = vdma_nop,
+   ._get_dma_residue = vdma_get_dma_residue,
+   ._dma_mem_alloc = vdma_mem_alloc,
+   ._dma_setup = vdma_dma_setup
}
 };
 
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] drm/nouveau: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index a6dbe8258040..ec4668a41e01 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -107,10 +107,10 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
 }
 
 const struct ttm_mem_type_manager_func nouveau_vram_manager = {
-   nouveau_vram_manager_init,
-   nouveau_vram_manager_fini,
-   nouveau_vram_manager_new,
-   nouveau_vram_manager_del,
+   .init = nouveau_vram_manager_init,
+   .takedown = nouveau_vram_manager_fini,
+   .get_node = nouveau_vram_manager_new,
+   .put_node = nouveau_vram_manager_del,
 };
 
 static int
@@ -184,11 +184,11 @@ nouveau_gart_manager_debug(struct ttm_mem_type_manager 
*man, const char *prefix)
 }
 
 const struct ttm_mem_type_manager_func nouveau_gart_manager = {
-   nouveau_gart_manager_init,
-   nouveau_gart_manager_fini,
-   nouveau_gart_manager_new,
-   nouveau_gart_manager_del,
-   nouveau_gart_manager_debug
+   .init = nouveau_gart_manager_init,
+   .takedown = nouveau_gart_manager_fini,
+   .get_node = nouveau_gart_manager_new,
+   .put_node = nouveau_gart_manager_del,
+   .debug = nouveau_gart_manager_debug
 };
 
 /*XXX*/
@@ -257,11 +257,11 @@ nv04_gart_manager_debug(struct ttm_mem_type_manager *man, 
const char *prefix)
 }
 
 const struct ttm_mem_type_manager_func nv04_gart_manager = {
-   nv04_gart_manager_init,
-   nv04_gart_manager_fini,
-   nv04_gart_manager_new,
-   nv04_gart_manager_del,
-   nv04_gart_manager_debug
+   .init = nv04_gart_manager_init,
+   .takedown = nv04_gart_manager_fini,
+   .get_node = nv04_gart_manager_new,
+   .put_node = nv04_gart_manager_del,
+   .debug = nv04_gart_manager_debug
 };
 
 int
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] cciss: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/block/cciss.h | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/block/cciss.h b/drivers/block/cciss.h
index 7fda30e4a241..428766d1ce80 100644
--- a/drivers/block/cciss.h
+++ b/drivers/block/cciss.h
@@ -402,27 +402,27 @@ static bool SA5_performant_intr_pending(ctlr_info_t *h)
 }
 
 static struct access_method SA5_access = {
-   SA5_submit_command,
-   SA5_intr_mask,
-   SA5_fifo_full,
-   SA5_intr_pending,
-   SA5_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_intr_mask,
+   .fifo_full = SA5_fifo_full,
+   .intr_pending = SA5_intr_pending,
+   .command_completed = SA5_completed,
 };
 
 static struct access_method SA5B_access = {
-SA5_submit_command,
-SA5B_intr_mask,
-SA5_fifo_full,
-SA5B_intr_pending,
-SA5_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5B_intr_mask,
+   .fifo_full = SA5_fifo_full,
+   .intr_pending = SA5B_intr_pending,
+   .command_completed = SA5_completed,
 };
 
 static struct access_method SA5_performant_access = {
-   SA5_submit_command,
-   SA5_performant_intr_mask,
-   SA5_fifo_full,
-   SA5_performant_intr_pending,
-   SA5_performant_completed,
+   .submit_command = SA5_submit_command,
+   .set_intr_mask = SA5_performant_intr_mask,
+   .fifo_full = SA5_fifo_full,
+   .intr_pending = SA5_performant_intr_pending,
+   .command_completed = SA5_performant_completed,
 };
 
 struct board_type {
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] RDMA/nes: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/infiniband/hw/nes/nes_cm.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/infiniband/hw/nes/nes_cm.c 
b/drivers/infiniband/hw/nes/nes_cm.c
index 8e703479e7ce..fb983df7c157 100644
--- a/drivers/infiniband/hw/nes/nes_cm.c
+++ b/drivers/infiniband/hw/nes/nes_cm.c
@@ -135,17 +135,17 @@ static void record_ird_ord(struct nes_cm_node *, u16, 
u16);
 /* instance of function pointers for client API */
 /* set address of this instance to cm_core->cm_ops at cm_core alloc */
 static const struct nes_cm_ops nes_cm_api = {
-   mini_cm_accelerated,
-   mini_cm_listen,
-   mini_cm_del_listen,
-   mini_cm_connect,
-   mini_cm_close,
-   mini_cm_accept,
-   mini_cm_reject,
-   mini_cm_recv_pkt,
-   mini_cm_dealloc_core,
-   mini_cm_get,
-   mini_cm_set
+   .accelerated = mini_cm_accelerated,
+   .listen = mini_cm_listen,
+   .stop_listener = mini_cm_del_listen,
+   .connect = mini_cm_connect,
+   .close = mini_cm_close,
+   .accept = mini_cm_accept,
+   .reject = mini_cm_reject,
+   .recv_pkt = mini_cm_recv_pkt,
+   .destroy_cm_core = mini_cm_dealloc_core,
+   .get = mini_cm_get,
+   .set = mini_cm_set
 };
 
 static struct nes_cm_core *g_cm_core;
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] x86/floppy: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 arch/x86/include/asm/floppy.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/floppy.h b/arch/x86/include/asm/floppy.h
index 1c7eefe32502..d0e4702883b9 100644
--- a/arch/x86/include/asm/floppy.h
+++ b/arch/x86/include/asm/floppy.h
@@ -229,18 +229,18 @@ static struct fd_routine_l {
int (*_dma_setup)(char *addr, unsigned long size, int mode, int io);
 } fd_routine[] = {
{
-   request_dma,
-   free_dma,
-   get_dma_residue,
-   dma_mem_alloc,
-   hard_dma_setup
+   ._request_dma = request_dma,
+   ._free_dma = free_dma,
+   ._get_dma_residue = get_dma_residue,
+   ._dma_mem_alloc = dma_mem_alloc,
+   ._dma_setup = hard_dma_setup
},
{
-   vdma_request_dma,
-   vdma_nop,
-   vdma_get_dma_residue,
-   vdma_mem_alloc,
-   vdma_dma_setup
+   ._request_dma = vdma_request_dma,
+   ._free_dma = vdma_nop,
+   ._get_dma_residue = vdma_get_dma_residue,
+   ._dma_mem_alloc = vdma_mem_alloc,
+   ._dma_setup = vdma_dma_setup
}
 };
 
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] drm/vmwgfx: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
index 170b61be1e4e..fec7348cea2c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c
@@ -164,9 +164,9 @@ static void vmw_gmrid_man_debug(struct ttm_mem_type_manager 
*man,
 }
 
 const struct ttm_mem_type_manager_func vmw_gmrid_manager_func = {
-   vmw_gmrid_man_init,
-   vmw_gmrid_man_takedown,
-   vmw_gmrid_man_get_node,
-   vmw_gmrid_man_put_node,
-   vmw_gmrid_man_debug
+   .init = vmw_gmrid_man_init,
+   .takedown = vmw_gmrid_man_takedown,
+   .get_node = vmw_gmrid_man_get_node,
+   .put_node = vmw_gmrid_man_put_node,
+   .debug = vmw_gmrid_man_debug
 };
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] net/x25: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 net/x25/sysctl_net_x25.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/x25/sysctl_net_x25.c b/net/x25/sysctl_net_x25.c
index 43239527a205..a06dfe143c67 100644
--- a/net/x25/sysctl_net_x25.c
+++ b/net/x25/sysctl_net_x25.c
@@ -70,7 +70,7 @@ static struct ctl_table x25_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
-   { 0, },
+   { },
 };
 
 void __init x25_register_sysctl(void)
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] RDMA/i40iw: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 128 +++
 drivers/infiniband/hw/i40iw/i40iw_uk.c   |  34 
 2 files changed, 80 insertions(+), 82 deletions(-)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c 
b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
index 392f78384a60..797f745a9a5b 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
@@ -4836,46 +4836,46 @@ void i40iw_vsi_stats_free(struct i40iw_sc_vsi *vsi)
 }
 
 static struct i40iw_cqp_ops iw_cqp_ops = {
-   i40iw_sc_cqp_init,
-   i40iw_sc_cqp_create,
-   i40iw_sc_cqp_post_sq,
-   i40iw_sc_cqp_get_next_send_wqe,
-   i40iw_sc_cqp_destroy,
-   i40iw_sc_poll_for_cqp_op_done
+   .cqp_init = i40iw_sc_cqp_init,
+   .cqp_create = i40iw_sc_cqp_create,
+   .cqp_post_sq = i40iw_sc_cqp_post_sq,
+   .cqp_get_next_send_wqe = i40iw_sc_cqp_get_next_send_wqe,
+   .cqp_destroy = i40iw_sc_cqp_destroy,
+   .poll_for_cqp_op_done = i40iw_sc_poll_for_cqp_op_done
 };
 
 static struct i40iw_ccq_ops iw_ccq_ops = {
-   i40iw_sc_ccq_init,
-   i40iw_sc_ccq_create,
-   i40iw_sc_ccq_destroy,
-   i40iw_sc_ccq_create_done,
-   i40iw_sc_ccq_get_cqe_info,
-   i40iw_sc_ccq_arm
+   .ccq_init = i40iw_sc_ccq_init,
+   .ccq_create = i40iw_sc_ccq_create,
+   .ccq_destroy = i40iw_sc_ccq_destroy,
+   .ccq_create_done = i40iw_sc_ccq_create_done,
+   .ccq_get_cqe_info = i40iw_sc_ccq_get_cqe_info,
+   .ccq_arm = i40iw_sc_ccq_arm
 };
 
 static struct i40iw_ceq_ops iw_ceq_ops = {
-   i40iw_sc_ceq_init,
-   i40iw_sc_ceq_create,
-   i40iw_sc_cceq_create_done,
-   i40iw_sc_cceq_destroy_done,
-   i40iw_sc_cceq_create,
-   i40iw_sc_ceq_destroy,
-   i40iw_sc_process_ceq
+   .ceq_init = i40iw_sc_ceq_init,
+   .ceq_create = i40iw_sc_ceq_create,
+   .cceq_create_done = i40iw_sc_cceq_create_done,
+   .cceq_destroy_done = i40iw_sc_cceq_destroy_done,
+   .cceq_create = i40iw_sc_cceq_create,
+   .ceq_destroy = i40iw_sc_ceq_destroy,
+   .process_ceq = i40iw_sc_process_ceq
 };
 
 static struct i40iw_aeq_ops iw_aeq_ops = {
-   i40iw_sc_aeq_init,
-   i40iw_sc_aeq_create,
-   i40iw_sc_aeq_destroy,
-   i40iw_sc_get_next_aeqe,
-   i40iw_sc_repost_aeq_entries,
-   i40iw_sc_aeq_create_done,
-   i40iw_sc_aeq_destroy_done
+   .aeq_init = i40iw_sc_aeq_init,
+   .aeq_create = i40iw_sc_aeq_create,
+   .aeq_destroy = i40iw_sc_aeq_destroy,
+   .get_next_aeqe = i40iw_sc_get_next_aeqe,
+   .repost_aeq_entries = i40iw_sc_repost_aeq_entries,
+   .aeq_create_done = i40iw_sc_aeq_create_done,
+   .aeq_destroy_done = i40iw_sc_aeq_destroy_done
 };
 
 /* iwarp pd ops */
 static struct i40iw_pd_ops iw_pd_ops = {
-   i40iw_sc_pd_init,
+   .pd_init = i40iw_sc_pd_init,
 };
 
 static struct i40iw_priv_qp_ops iw_priv_qp_ops = {
@@ -4894,53 +4894,51 @@ static struct i40iw_priv_qp_ops iw_priv_qp_ops = {
 };
 
 static struct i40iw_priv_cq_ops iw_priv_cq_ops = {
-   i40iw_sc_cq_init,
-   i40iw_sc_cq_create,
-   i40iw_sc_cq_destroy,
-   i40iw_sc_cq_modify,
+   .cq_init = i40iw_sc_cq_init,
+   .cq_create = i40iw_sc_cq_create,
+   .cq_destroy = i40iw_sc_cq_destroy,
+   .cq_modify = i40iw_sc_cq_modify,
 };
 
 static struct i40iw_mr_ops iw_mr_ops = {
-   i40iw_sc_alloc_stag,
-   i40iw_sc_mr_reg_non_shared,
-   i40iw_sc_mr_reg_shared,
-   i40iw_sc_dealloc_stag,
-   i40iw_sc_query_stag,
-   i40iw_sc_mw_alloc
+   .alloc_stag = i40iw_sc_alloc_stag,
+   .mr_reg_non_shared = i40iw_sc_mr_reg_non_shared,
+   .mr_reg_shared = i40iw_sc_mr_reg_shared,
+   .dealloc_stag = i40iw_sc_dealloc_stag,
+   .query_stag = i40iw_sc_query_stag,
+   .mw_alloc = i40iw_sc_mw_alloc
 };
 
 static struct i40iw_cqp_misc_ops iw_cqp_misc_ops = {
-   i40iw_sc_manage_push_page,
-   i40iw_sc_manage_hmc_pm_func_table,
-   i40iw_sc_set_hmc_resource_profile,
-   i40iw_sc_commit_fpm_values,
-   i40iw_sc_query_fpm_values,
-   i40iw_sc_static_hmc_pages_allocated,
-   i40iw_sc_add_arp_cache_entry,
-   i40iw_sc_del_arp_cache_entry,
-   i40iw_sc_query_arp_cache_entry,
-   i40iw_sc_manage_apbvt_entry,
-   i40iw_sc_manage_qhash_table_entry,
-   i40iw_sc_alloc_local_mac_ipaddr_entry,
-   i40iw_sc_add_local_mac_ipaddr_entry,
-   i40iw_sc_del_local_mac_ipaddr_entry,
-   i40iw_sc_cqp_nop,
-   i40iw_sc_commit_fpm_values_done,
-   i40iw_sc_query_fpm_values_done,
-   i40iw_sc_manage_hmc_pm_func_table_done,
-   i40iw_sc_suspend_qp,
-   i40iw_sc_resume_qp
+  

Re: [PATCH] sbus: char: Move D7S_MINOR to include/linux/miscdevice.h

[Julian Calaby]

Hi Corentin,

On Fri, Dec 16, 2016 at 6:47 AM, Corentin Labbe
 wrote:
> This patch move the define for D7S_MINOR to include/linux/miscdevice.h.
> It's better that all minor number are in the same place.
>
> Signed-off-by: Corentin Labbe 
> ---
>  drivers/sbus/char/display7seg.c | 1 -
>  include/linux/miscdevice.h  | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/sbus/char/display7seg.c b/drivers/sbus/char/display7seg.c
> index 33fbe82..48a5df0 100644
> --- a/drivers/sbus/char/display7seg.c
> +++ b/drivers/sbus/char/display7seg.c
> @@ -22,7 +22,6 @@
>
>  #include 
>
> -#define D7S_MINOR  193
>  #define DRIVER_NAME"d7s"
>  #define PFXDRIVER_NAME ": "
>
> diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h
> index 5385d95..b1ba37aef 100644
> --- a/include/linux/miscdevice.h
> +++ b/include/linux/miscdevice.h
> @@ -33,6 +33,7 @@
>  #define I2O_MINOR  166
>  #define HWRNG_MINOR183
>  #define MICROCODE_MINOR184
> +#define D7S_MINOR  193

I was going to say "why not change the name to something more
descriptive" however they're all very abbreviated, so maybe consider a
second patch series to describe what each of these is for?

>  #define VFIO_MINOR 196
>  #define TUN_MINOR  200
>  #define CUSE_MINOR 203

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/

[PATCH] ACPICA: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/acpi/acpica/hwxfsleep.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/acpica/hwxfsleep.c b/drivers/acpi/acpica/hwxfsleep.c
index f76e0eab32b8..25cd5c66e102 100644
--- a/drivers/acpi/acpica/hwxfsleep.c
+++ b/drivers/acpi/acpica/hwxfsleep.c
@@ -70,11 +70,12 @@ static acpi_status acpi_hw_sleep_dispatch(u8 sleep_state, 
u32 function_id);
 /* Legacy functions are optional, based upon ACPI_REDUCED_HARDWARE */
 
 static struct acpi_sleep_functions acpi_sleep_dispatch[] = {
-   {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
-acpi_hw_extended_sleep},
-   {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
-acpi_hw_extended_wake_prep},
-   {ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake), acpi_hw_extended_wake}
+   { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_sleep),
+ .extended_function = acpi_hw_extended_sleep },
+   { .legacy_function = 
ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake_prep),
+ .extended_function = acpi_hw_extended_wake_prep },
+   { .legacy_function = ACPI_HW_OPTIONAL_FUNCTION(acpi_hw_legacy_wake),
+ .extended_function = acpi_hw_extended_wake }
 };
 
 /*
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] video: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/video/fbdev/matrox/matroxfb_DAC1064.c | 10 --
 drivers/video/fbdev/matrox/matroxfb_Ti3026.c  |  5 -
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/matrox/matroxfb_DAC1064.c 
b/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
index a01147fdf270..5d896f879ff9 100644
--- a/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
+++ b/drivers/video/fbdev/matrox/matroxfb_DAC1064.c
@@ -1088,14 +1088,20 @@ static void MGAG100_restore(struct matrox_fb_info 
*minfo)
 
 #ifdef CONFIG_FB_MATROX_MYSTIQUE
 struct matrox_switch matrox_mystique = {
-   MGA1064_preinit, MGA1064_reset, MGA1064_init, MGA1064_restore,
+   .preinit = MGA1064_preinit,
+   .reset = MGA1064_reset,
+   .init = MGA1064_init,
+   .restore = MGA1064_restore,
 };
 EXPORT_SYMBOL(matrox_mystique);
 #endif
 
 #ifdef CONFIG_FB_MATROX_G
 struct matrox_switch matrox_G100 = {
-   MGAG100_preinit, MGAG100_reset, MGAG100_init, MGAG100_restore,
+   .preinit = MGAG100_preinit,
+   .reset = MGAG100_reset,
+   .init = MGAG100_init,
+   .restore = MGAG100_restore,
 };
 EXPORT_SYMBOL(matrox_G100);
 #endif
diff --git a/drivers/video/fbdev/matrox/matroxfb_Ti3026.c 
b/drivers/video/fbdev/matrox/matroxfb_Ti3026.c
index 68fa037d8cbc..0273351b2342 100644
--- a/drivers/video/fbdev/matrox/matroxfb_Ti3026.c
+++ b/drivers/video/fbdev/matrox/matroxfb_Ti3026.c
@@ -738,7 +738,10 @@ static int Ti3026_preinit(struct matrox_fb_info *minfo)
 }
 
 struct matrox_switch matrox_millennium = {
-   Ti3026_preinit, Ti3026_reset, Ti3026_init, Ti3026_restore
+   .preinit = Ti3026_preinit,
+   .reset = Ti3026_reset,
+   .init = Ti3026_init,
+   .restore = Ti3026_restore
 };
 EXPORT_SYMBOL(matrox_millennium);
 #endif
-- 
2.7.4


-- 
Kees Cook
Nexus Security

[PATCH] RDMA/i40iw: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/infiniband/hw/i40iw/i40iw_ctrl.c | 128 +++
 drivers/infiniband/hw/i40iw/i40iw_uk.c   |  34 
 2 files changed, 80 insertions(+), 82 deletions(-)

diff --git a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c 
b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
index 392f78384a60..797f745a9a5b 100644
--- a/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
+++ b/drivers/infiniband/hw/i40iw/i40iw_ctrl.c
@@ -4836,46 +4836,46 @@ void i40iw_vsi_stats_free(struct i40iw_sc_vsi *vsi)
 }
 
 static struct i40iw_cqp_ops iw_cqp_ops = {
-   i40iw_sc_cqp_init,
-   i40iw_sc_cqp_create,
-   i40iw_sc_cqp_post_sq,
-   i40iw_sc_cqp_get_next_send_wqe,
-   i40iw_sc_cqp_destroy,
-   i40iw_sc_poll_for_cqp_op_done
+   .cqp_init = i40iw_sc_cqp_init,
+   .cqp_create = i40iw_sc_cqp_create,
+   .cqp_post_sq = i40iw_sc_cqp_post_sq,
+   .cqp_get_next_send_wqe = i40iw_sc_cqp_get_next_send_wqe,
+   .cqp_destroy = i40iw_sc_cqp_destroy,
+   .poll_for_cqp_op_done = i40iw_sc_poll_for_cqp_op_done
 };
 
 static struct i40iw_ccq_ops iw_ccq_ops = {
-   i40iw_sc_ccq_init,
-   i40iw_sc_ccq_create,
-   i40iw_sc_ccq_destroy,
-   i40iw_sc_ccq_create_done,
-   i40iw_sc_ccq_get_cqe_info,
-   i40iw_sc_ccq_arm
+   .ccq_init = i40iw_sc_ccq_init,
+   .ccq_create = i40iw_sc_ccq_create,
+   .ccq_destroy = i40iw_sc_ccq_destroy,
+   .ccq_create_done = i40iw_sc_ccq_create_done,
+   .ccq_get_cqe_info = i40iw_sc_ccq_get_cqe_info,
+   .ccq_arm = i40iw_sc_ccq_arm
 };
 
 static struct i40iw_ceq_ops iw_ceq_ops = {
-   i40iw_sc_ceq_init,
-   i40iw_sc_ceq_create,
-   i40iw_sc_cceq_create_done,
-   i40iw_sc_cceq_destroy_done,
-   i40iw_sc_cceq_create,
-   i40iw_sc_ceq_destroy,
-   i40iw_sc_process_ceq
+   .ceq_init = i40iw_sc_ceq_init,
+   .ceq_create = i40iw_sc_ceq_create,
+   .cceq_create_done = i40iw_sc_cceq_create_done,
+   .cceq_destroy_done = i40iw_sc_cceq_destroy_done,
+   .cceq_create = i40iw_sc_cceq_create,
+   .ceq_destroy = i40iw_sc_ceq_destroy,
+   .process_ceq = i40iw_sc_process_ceq
 };
 
 static struct i40iw_aeq_ops iw_aeq_ops = {
-   i40iw_sc_aeq_init,
-   i40iw_sc_aeq_create,
-   i40iw_sc_aeq_destroy,
-   i40iw_sc_get_next_aeqe,
-   i40iw_sc_repost_aeq_entries,
-   i40iw_sc_aeq_create_done,
-   i40iw_sc_aeq_destroy_done
+   .aeq_init = i40iw_sc_aeq_init,
+   .aeq_create = i40iw_sc_aeq_create,
+   .aeq_destroy = i40iw_sc_aeq_destroy,
+   .get_next_aeqe = i40iw_sc_get_next_aeqe,
+   .repost_aeq_entries = i40iw_sc_repost_aeq_entries,
+   .aeq_create_done = i40iw_sc_aeq_create_done,
+   .aeq_destroy_done = i40iw_sc_aeq_destroy_done
 };
 
 /* iwarp pd ops */
 static struct i40iw_pd_ops iw_pd_ops = {
-   i40iw_sc_pd_init,
+   .pd_init = i40iw_sc_pd_init,
 };
 
 static struct i40iw_priv_qp_ops iw_priv_qp_ops = {
@@ -4894,53 +4894,51 @@ static struct i40iw_priv_qp_ops iw_priv_qp_ops = {
 };
 
 static struct i40iw_priv_cq_ops iw_priv_cq_ops = {
-   i40iw_sc_cq_init,
-   i40iw_sc_cq_create,
-   i40iw_sc_cq_destroy,
-   i40iw_sc_cq_modify,
+   .cq_init = i40iw_sc_cq_init,
+   .cq_create = i40iw_sc_cq_create,
+   .cq_destroy = i40iw_sc_cq_destroy,
+   .cq_modify = i40iw_sc_cq_modify,
 };
 
 static struct i40iw_mr_ops iw_mr_ops = {
-   i40iw_sc_alloc_stag,
-   i40iw_sc_mr_reg_non_shared,
-   i40iw_sc_mr_reg_shared,
-   i40iw_sc_dealloc_stag,
-   i40iw_sc_query_stag,
-   i40iw_sc_mw_alloc
+   .alloc_stag = i40iw_sc_alloc_stag,
+   .mr_reg_non_shared = i40iw_sc_mr_reg_non_shared,
+   .mr_reg_shared = i40iw_sc_mr_reg_shared,
+   .dealloc_stag = i40iw_sc_dealloc_stag,
+   .query_stag = i40iw_sc_query_stag,
+   .mw_alloc = i40iw_sc_mw_alloc
 };
 
 static struct i40iw_cqp_misc_ops iw_cqp_misc_ops = {
-   i40iw_sc_manage_push_page,
-   i40iw_sc_manage_hmc_pm_func_table,
-   i40iw_sc_set_hmc_resource_profile,
-   i40iw_sc_commit_fpm_values,
-   i40iw_sc_query_fpm_values,
-   i40iw_sc_static_hmc_pages_allocated,
-   i40iw_sc_add_arp_cache_entry,
-   i40iw_sc_del_arp_cache_entry,
-   i40iw_sc_query_arp_cache_entry,
-   i40iw_sc_manage_apbvt_entry,
-   i40iw_sc_manage_qhash_table_entry,
-   i40iw_sc_alloc_local_mac_ipaddr_entry,
-   i40iw_sc_add_local_mac_ipaddr_entry,
-   i40iw_sc_del_local_mac_ipaddr_entry,
-   i40iw_sc_cqp_nop,
-   i40iw_sc_commit_fpm_values_done,
-   i40iw_sc_query_fpm_values_done,
-   i40iw_sc_manage_hmc_pm_func_table_done,
-   i40iw_sc_suspend_qp,
-   i40iw_sc_resume_qp
+   .manage_push_page = 

Re: [PATCH] sbus: char: Move D7S_MINOR to include/linux/miscdevice.h

[Julian Calaby]

Hi Corentin,

On Fri, Dec 16, 2016 at 6:47 AM, Corentin Labbe
 wrote:
> This patch move the define for D7S_MINOR to include/linux/miscdevice.h.
> It's better that all minor number are in the same place.
>
> Signed-off-by: Corentin Labbe 
> ---
>  drivers/sbus/char/display7seg.c | 1 -
>  include/linux/miscdevice.h  | 1 +
>  2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/sbus/char/display7seg.c b/drivers/sbus/char/display7seg.c
> index 33fbe82..48a5df0 100644
> --- a/drivers/sbus/char/display7seg.c
> +++ b/drivers/sbus/char/display7seg.c
> @@ -22,7 +22,6 @@
>
>  #include 
>
> -#define D7S_MINOR  193
>  #define DRIVER_NAME"d7s"
>  #define PFXDRIVER_NAME ": "
>
> diff --git a/include/linux/miscdevice.h b/include/linux/miscdevice.h
> index 5385d95..b1ba37aef 100644
> --- a/include/linux/miscdevice.h
> +++ b/include/linux/miscdevice.h
> @@ -33,6 +33,7 @@
>  #define I2O_MINOR  166
>  #define HWRNG_MINOR183
>  #define MICROCODE_MINOR184
> +#define D7S_MINOR  193

I was going to say "why not change the name to something more
descriptive" however they're all very abbreviated, so maybe consider a
second patch series to describe what each of these is for?

>  #define VFIO_MINOR 196
>  #define TUN_MINOR  200
>  #define CUSE_MINOR 203

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/