Beagle x15: perf test -v hangs on Linux 4.9 and 4.14

[Naresh Kamboju]

Perf test -v hangs on beagle x15 device running Linux version stable
4.9 and 4.14 kernel. ( gcc version 7.3.0).

X15

Test breakpoint overflow signal handler: FAILED
Test breakpoint overflow sampling:
--- start ---
test child forked, pid 381
***Hangs Forever***

Debug log with strace output,

strace -f perf test -v
...
[pid   346] perf_event_open({type=PERF_TYPE_BREAKPOINT,
size=PERF_ATTR_SIZE_VER5, config=0, ...}, 0, -1, -1,
PERF_FLAG_FD_CLOEXEC) = 3
[pid   346] fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK|O_ASYNC) = 0
[pid   346] fcntl64(3, F_SETSIG, SIGIO) = 0
[pid   346] getpid()= 346
[pid   346] fcntl64(3, F_SETOWN, 346)   = 0
[pid   346] ioctl(3, PERF_EVENT_IOC_RESET, 0) = 0
[pid   346] ioctl(3, PERF_EVENT_IOC_ENABLE, 0) = 0
[pid   346] --- SIGIO {si_signo=SIGIO, si_code=POLL_IN, si_band=65} ---
[pid   346] rt_sigreturn({mask=[WINCH]}) = 0
...
popping up this log continuesly

[pid   346] --- SIGIO {si_signo=SIGIO, si_code=POLL_IN, si_band=65} ---
[pid   346] rt_sigreturn({mask=[WINCH]}) = 0"}

Ref:
Juno/x15: perf: Test breakpoint overflow sampling and test hangs
https://bugs.linaro.org/show_bug.cgi?id=4321
Full test log,
https://lkft.validation.linaro.org/scheduler/job/655038#L1794
Kernel Config,
http://snapshots.linaro.org/openembedded/lkft/lkft/sumo/am57xx-evm/lkft/linux-stable-rc-4.9/524/config

Best regards
Naresh Kamboju

Re: [BUG linux-4.9.x] xen hotplug cpu leads to 100% steal usage

[Dongli Zhang]

Hi Thomas,

On 3/2/19 7:43 AM, Thomas Gleixner wrote:
> On Thu, 28 Feb 2019, Dongli Zhang wrote:
>>
>> The root cause is that the return type of jiffies_to_usecs() is 'unsigned 
>> int',
>> but not 'unsigned long'. As a result, the leading 32 bits are discarded.
> 
> Errm. No. The root cause is that jiffies_to_usecs() is used for that in the
> first place. The function has been that way forever and all usage sites
> (except a broken dev_debug print in infiniband) feed delta values. Yes, it
> could have documentation

Thank you very much for the explanation. It would help the developers clarify
the usage of jiffies_to_usecs() (which we should always feed with dealt value)
with comments above it.

Indeed, the input value in this bug is also a delta value. Because of the
special mechanisms used by xen to account steal clock, the initial delta value
is always very large, only when the new cpu is added after the VM is already up
for very long time.

Dongli Zhang


> 
>> jiffies_to_usecs() is indirectly triggered by cputime_to_nsecs() at line 264.
>> If guest is already up for long time, the initial steal time for new vcpu 
>> might
>> be large and the leading 32 bits of jiffies_to_usecs() would be discarded.
> 
>> So far, I have two solutions:
>>
>> 1. Change the return type from 'unsigned int' to 'unsigned long' as in above
>> link and I am afraid it would bring side effect. The return type in latest
>> mainline kernel is still 'unsigned int'.
> 
> Changing it to unsigned long would just solve the issue for 64bit.
> 
> Thanks,
> 
>   tglx
> 

Re: [BUG linux-4.9.x] xen hotplug cpu leads to 100% steal usage

[Dongli Zhang]

Hi Juergen,

On 3/4/19 4:14 PM, Juergen Gross wrote:
> On 01/03/2019 03:35, Dongli Zhang wrote:
>> This issue is only for stable 4.9.x (e.g., 4.9.160), while the root cause is
>> still in the lasted mainline kernel.
>>
>> This is obviated by new feature patch set ended with b672592f0221
>> ("sched/cputime: Remove generic asm headers").
>>
>> After xen guest is up for long time, once we hotplug new vcpu, the 
>> corresponding
>> steal usage might become 100% and the steal time from /proc/stat would 
>> increase
>> abnormally.
>>
>> As we cannot wait for long time to reproduce the issue, here is how I 
>> reproduce
>> it on purpose by accounting a large initial steal clock for new vcpu 2 and 3.
>>
>> 1. Apply the below patch to guest 4.9.160 to account large initial steal 
>> clock
>> for new vcpu 2 and 3:
>>
>> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
>> index ac5f23f..3cf629e 100644
>> --- a/drivers/xen/time.c
>> +++ b/drivers/xen/time.c
>> @@ -85,7 +85,14 @@ u64 xen_steal_clock(int cpu)
>> struct vcpu_runstate_info state;
>>  
>> xen_get_runstate_snapshot_cpu(&state, cpu);
>> -   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
>> +
>> +   if (cpu == 2 || cpu == 3)
>> +   return state.time[RUNSTATE_runnable]
>> +  + state.time[RUNSTATE_offline]
>> +  + 0x00071e87e677aa12;
>> +   else
>> +   return state.time[RUNSTATE_runnable]
>> +  + state.time[RUNSTATE_offline];
>>  }
>>  
>>  void xen_setup_runstate_info(int cpu)
>>
>>
>> 2. Boot hvm guest with "vcpus=2" and "maxvcpus=4". By default, VM boot with
>> vcpu 0 and 1.
>>
>> 3. Hotplug vcpu 2 and 3 via "xl vcpu-set  4" on dom0.
>>
>> In my env, the steal becomes 100% within 10s after the "xl vcpu-set" command 
>> on
>> dom0.
>>
>> I can reproduce on kvm with similar method. However, as the initial steal 
>> clock
>> on kvm guest is always 0, I do not think it is easy to hit this issue on kvm.
>>
>> 
>>
>> The root cause is that the return type of jiffies_to_usecs() is 'unsigned 
>> int',
>> but not 'unsigned long'. As a result, the leading 32 bits are discarded.
>>
>> jiffies_to_usecs() is indirectly triggered by cputime_to_nsecs() at line 264.
>> If guest is already up for long time, the initial steal time for new vcpu 
>> might
>> be large and the leading 32 bits of jiffies_to_usecs() would be discarded.
>>
>> As a result, the steal at line 259 is always large and the
>> this_rq()->prev_steal_time at line 264 is always small. The difference at 
>> line
>> 260 is always large during each time steal_account_process_time() is 
>> involved.
>> Finally, the steal time in /proc/stat would increase abnormally.
>>
>> 252 static __always_inline cputime_t steal_account_process_time(cputime_t 
>> maxtime)
>> 253 {
>> 254 #ifdef CONFIG_PARAVIRT
>> 255 if (static_key_false(¶virt_steal_enabled)) {
>> 256 cputime_t steal_cputime;
>> 257 u64 steal;
>> 258 
>> 259 steal = paravirt_steal_clock(smp_processor_id());
>> 260 steal -= this_rq()->prev_steal_time;
>> 261 
>> 262 steal_cputime = min(nsecs_to_cputime(steal), maxtime);
>> 263 account_steal_time(steal_cputime);
>> 264 this_rq()->prev_steal_time += 
>> cputime_to_nsecs(steal_cputime);
>> 265 
>> 266 return steal_cputime;
>> 267 }
>> 268 #endif
>> 269 return 0;
>> 270 }
>>
>> 
>>
>> I have emailed the kernel mailing list about the return type of
>> jiffies_to_usecs() and jiffies_to_msecs():
>>
>> https://lkml.org/lkml/2019/2/26/899
>>
>>
>> So far, I have two solutions:
>>
>> 1. Change the return type from 'unsigned int' to 'unsigned long' as in above
>> link and I am afraid it would bring side effect. The return type in latest
>> mainline kernel is still 'unsigned int'.
>>
>> 2. Something like below based on stable 4.9.160:
> 
> 3. use jiffies64_to_nsecs() instead of trying to open code it.

Thank you very much for the suggestion!

I have tested that jiffies64_to_nsecs() works well by reproducing the issue in
kvm guest on purpose.

diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 734377a..94aff43 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -287,13 +287,13 @@ extern unsigned long preset_lpj;
 extern unsigned int jiffies_to_msecs(const unsigned long j);
 extern unsigned int jiffies_to_usecs(const unsigned long j);

+extern u64 jiffies64_to_nsecs(u64 j);
+
 static inline u64 jiffies_to_nsecs(const unsigned long j)
 {
-   return (u64)jiffies_to_usecs(j) * NSEC_PER_USEC;
+   return jiffies64_to_nsecs(j);
 }

-extern u64 jiffies64_to_nsecs(u64 j);



Below is the patch used to reproduce on kvm. cpu 2 is added to reproduce on
purpose via "device_add
qemu64-x86_64-cpu,id=co

Re: [BUG linux-4.9.x] xen hotplug cpu leads to 100% steal usage

[Juergen Gross]

On 01/03/2019 03:35, Dongli Zhang wrote:
> This issue is only for stable 4.9.x (e.g., 4.9.160), while the root cause is
> still in the lasted mainline kernel.
> 
> This is obviated by new feature patch set ended with b672592f0221
> ("sched/cputime: Remove generic asm headers").
> 
> After xen guest is up for long time, once we hotplug new vcpu, the 
> corresponding
> steal usage might become 100% and the steal time from /proc/stat would 
> increase
> abnormally.
> 
> As we cannot wait for long time to reproduce the issue, here is how I 
> reproduce
> it on purpose by accounting a large initial steal clock for new vcpu 2 and 3.
> 
> 1. Apply the below patch to guest 4.9.160 to account large initial steal clock
> for new vcpu 2 and 3:
> 
> diff --git a/drivers/xen/time.c b/drivers/xen/time.c
> index ac5f23f..3cf629e 100644
> --- a/drivers/xen/time.c
> +++ b/drivers/xen/time.c
> @@ -85,7 +85,14 @@ u64 xen_steal_clock(int cpu)
> struct vcpu_runstate_info state;
>  
> xen_get_runstate_snapshot_cpu(&state, cpu);
> -   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
> +
> +   if (cpu == 2 || cpu == 3)
> +   return state.time[RUNSTATE_runnable]
> +  + state.time[RUNSTATE_offline]
> +  + 0x00071e87e677aa12;
> +   else
> +   return state.time[RUNSTATE_runnable]
> +  + state.time[RUNSTATE_offline];
>  }
>  
>  void xen_setup_runstate_info(int cpu)
> 
> 
> 2. Boot hvm guest with "vcpus=2" and "maxvcpus=4". By default, VM boot with
> vcpu 0 and 1.
> 
> 3. Hotplug vcpu 2 and 3 via "xl vcpu-set  4" on dom0.
> 
> In my env, the steal becomes 100% within 10s after the "xl vcpu-set" command 
> on
> dom0.
> 
> I can reproduce on kvm with similar method. However, as the initial steal 
> clock
> on kvm guest is always 0, I do not think it is easy to hit this issue on kvm.
> 
> 
> 
> The root cause is that the return type of jiffies_to_usecs() is 'unsigned 
> int',
> but not 'unsigned long'. As a result, the leading 32 bits are discarded.
> 
> jiffies_to_usecs() is indirectly triggered by cputime_to_nsecs() at line 264.
> If guest is already up for long time, the initial steal time for new vcpu 
> might
> be large and the leading 32 bits of jiffies_to_usecs() would be discarded.
> 
> As a result, the steal at line 259 is always large and the
> this_rq()->prev_steal_time at line 264 is always small. The difference at line
> 260 is always large during each time steal_account_process_time() is involved.
> Finally, the steal time in /proc/stat would increase abnormally.
> 
> 252 static __always_inline cputime_t steal_account_process_time(cputime_t 
> maxtime)
> 253 {
> 254 #ifdef CONFIG_PARAVIRT
> 255 if (static_key_false(¶virt_steal_enabled)) {
> 256 cputime_t steal_cputime;
> 257 u64 steal;
> 258 
> 259 steal = paravirt_steal_clock(smp_processor_id());
> 260 steal -= this_rq()->prev_steal_time;
> 261 
> 262 steal_cputime = min(nsecs_to_cputime(steal), maxtime);
> 263 account_steal_time(steal_cputime);
> 264 this_rq()->prev_steal_time += 
> cputime_to_nsecs(steal_cputime);
> 265 
> 266 return steal_cputime;
> 267 }
> 268 #endif
> 269 return 0;
> 270 }
> 
> 
> 
> I have emailed the kernel mailing list about the return type of
> jiffies_to_usecs() and jiffies_to_msecs():
> 
> https://lkml.org/lkml/2019/2/26/899
> 
> 
> So far, I have two solutions:
> 
> 1. Change the return type from 'unsigned int' to 'unsigned long' as in above
> link and I am afraid it would bring side effect. The return type in latest
> mainline kernel is still 'unsigned int'.
> 
> 2. Something like below based on stable 4.9.160:

3. use jiffies64_to_nsecs() instead of trying to open code it.


Juergen

Re: [BUG linux-4.9.x] xen hotplug cpu leads to 100% steal usage

[Thomas Gleixner]

On Thu, 28 Feb 2019, Dongli Zhang wrote:
> 
> The root cause is that the return type of jiffies_to_usecs() is 'unsigned 
> int',
> but not 'unsigned long'. As a result, the leading 32 bits are discarded.

Errm. No. The root cause is that jiffies_to_usecs() is used for that in the
first place. The function has been that way forever and all usage sites
(except a broken dev_debug print in infiniband) feed delta values. Yes, it
could have documentation

> jiffies_to_usecs() is indirectly triggered by cputime_to_nsecs() at line 264.
> If guest is already up for long time, the initial steal time for new vcpu 
> might
> be large and the leading 32 bits of jiffies_to_usecs() would be discarded.

> So far, I have two solutions:
> 
> 1. Change the return type from 'unsigned int' to 'unsigned long' as in above
> link and I am afraid it would bring side effect. The return type in latest
> mainline kernel is still 'unsigned int'.

Changing it to unsigned long would just solve the issue for 64bit.

Thanks,

tglx

[BUG linux-4.9.x] xen hotplug cpu leads to 100% steal usage

[Dongli Zhang]

This issue is only for stable 4.9.x (e.g., 4.9.160), while the root cause is
still in the lasted mainline kernel.

This is obviated by new feature patch set ended with b672592f0221
("sched/cputime: Remove generic asm headers").

After xen guest is up for long time, once we hotplug new vcpu, the corresponding
steal usage might become 100% and the steal time from /proc/stat would increase
abnormally.

As we cannot wait for long time to reproduce the issue, here is how I reproduce
it on purpose by accounting a large initial steal clock for new vcpu 2 and 3.

1. Apply the below patch to guest 4.9.160 to account large initial steal clock
for new vcpu 2 and 3:

diff --git a/drivers/xen/time.c b/drivers/xen/time.c
index ac5f23f..3cf629e 100644
--- a/drivers/xen/time.c
+++ b/drivers/xen/time.c
@@ -85,7 +85,14 @@ u64 xen_steal_clock(int cpu)
struct vcpu_runstate_info state;
 
xen_get_runstate_snapshot_cpu(&state, cpu);
-   return state.time[RUNSTATE_runnable] + state.time[RUNSTATE_offline];
+
+   if (cpu == 2 || cpu == 3)
+   return state.time[RUNSTATE_runnable]
+  + state.time[RUNSTATE_offline]
+  + 0x00071e87e677aa12;
+   else
+   return state.time[RUNSTATE_runnable]
+  + state.time[RUNSTATE_offline];
 }
 
 void xen_setup_runstate_info(int cpu)


2. Boot hvm guest with "vcpus=2" and "maxvcpus=4". By default, VM boot with
vcpu 0 and 1.

3. Hotplug vcpu 2 and 3 via "xl vcpu-set  4" on dom0.

In my env, the steal becomes 100% within 10s after the "xl vcpu-set" command on
dom0.

I can reproduce on kvm with similar method. However, as the initial steal clock
on kvm guest is always 0, I do not think it is easy to hit this issue on kvm.



The root cause is that the return type of jiffies_to_usecs() is 'unsigned int',
but not 'unsigned long'. As a result, the leading 32 bits are discarded.

jiffies_to_usecs() is indirectly triggered by cputime_to_nsecs() at line 264.
If guest is already up for long time, the initial steal time for new vcpu might
be large and the leading 32 bits of jiffies_to_usecs() would be discarded.

As a result, the steal at line 259 is always large and the
this_rq()->prev_steal_time at line 264 is always small. The difference at line
260 is always large during each time steal_account_process_time() is involved.
Finally, the steal time in /proc/stat would increase abnormally.

252 static __always_inline cputime_t steal_account_process_time(cputime_t 
maxtime)
253 {
254 #ifdef CONFIG_PARAVIRT
255 if (static_key_false(¶virt_steal_enabled)) {
256 cputime_t steal_cputime;
257 u64 steal;
258 
259 steal = paravirt_steal_clock(smp_processor_id());
260 steal -= this_rq()->prev_steal_time;
261 
262 steal_cputime = min(nsecs_to_cputime(steal), maxtime);
263 account_steal_time(steal_cputime);
264 this_rq()->prev_steal_time += 
cputime_to_nsecs(steal_cputime);
265 
266 return steal_cputime;
267 }
268 #endif
269 return 0;
270 }



I have emailed the kernel mailing list about the return type of
jiffies_to_usecs() and jiffies_to_msecs():

https://lkml.org/lkml/2019/2/26/899


So far, I have two solutions:

1. Change the return type from 'unsigned int' to 'unsigned long' as in above
link and I am afraid it would bring side effect. The return type in latest
mainline kernel is still 'unsigned int'.

2. Something like below based on stable 4.9.160:

diff --git a/include/linux/jiffies.h b/include/linux/jiffies.h
index 734377a..9b1fc40 100644
--- a/include/linux/jiffies.h
+++ b/include/linux/jiffies.h
@@ -286,10 +286,11 @@ extern unsigned long preset_lpj;
  */
 extern unsigned int jiffies_to_msecs(const unsigned long j);
 extern unsigned int jiffies_to_usecs(const unsigned long j);
+extern unsigned long jiffies_to_usecs64(const unsigned long j);
 
 static inline u64 jiffies_to_nsecs(const unsigned long j)
 {
-   return (u64)jiffies_to_usecs(j) * NSEC_PER_USEC;
+   return (u64)jiffies_to_usecs64(j) * NSEC_PER_USEC;
 }
 
 extern u64 jiffies64_to_nsecs(u64 j);
diff --git a/kernel/time/time.c b/kernel/time/time.c
index a5b6d98..256c147 100644
--- a/kernel/time/time.c
+++ b/kernel/time/time.c
@@ -288,6 +288,27 @@ unsigned int jiffies_to_usecs(const unsigned long j)
 }
 EXPORT_SYMBOL(jiffies_to_usecs);
 
+unsigned long jiffies_to_usecs64(const unsigned long j)
+{
+   /*
+* Hz usually doesn't go much further MSEC_PER_SEC.
+* jiffies_to_usecs() and usecs_to_jiffies() depend on that.
+*/
+   BUILD_BUG_ON(HZ > USEC_PER_SEC);
+
+#if !(USEC_PER_SEC % HZ)
+   return (USEC_PER_SEC / HZ) * j;
+#else
+# if BITS_PER_LONG == 32
+   return (HZ_TO_USEC_MUL32 * j) >> HZ_TO_USEC_SHR32;
+# else
+   return (j * HZ_TO_USEC_N

Re: stable-rc/linux-4.9.y build: 183 builds: 179 failed, 4 passed, 179 errors (v4.9.71-115-gd4b9c892aea4)

[gregkh]

On Thu, Dec 21, 2017 at 10:19:27AM -0800, Eduardo Valentin wrote:
> On Thu, Dec 21, 2017 at 03:49:20PM +0100, gregkh wrote:
> > On Thu, Dec 21, 2017 at 12:33:45PM +0100, Arnd Bergmann wrote:
> > > On Thu, Dec 21, 2017 at 12:06 PM, kernelci.org bot  
> > > wrote:
> > > > stable-rc/linux-4.9.y build: 183 builds: 179 failed, 4 passed, 179 
> > > > errors (v4.9.71-115-gd4b9c892aea4)
> > > >
> > > > Full Build Summary: 
> > > > https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.71-115-gd4b9c892aea4/
> > > >
> > > > Tree: stable-rc
> > > > Branch: linux-4.9.y
> > > > Git Describe: v4.9.71-115-gd4b9c892aea4
> > > > Git Commit: d4b9c892aea47e47ebc74e59533cef79f9ca30eb
> > > > Git URL: 
> > > > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > > Built: 4 unique architectures
> > > >
> > > > Build Failures Detected:
> > > >
> > > > arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
> > > >
> > > > allnoconfig: FAIL
> > > > defconfig: FAIL
> > > > tinyconfig: FAIL
> > > >
> > > > arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
> > > >
> > > > acs5k_defconfig: FAIL
> > > > acs5k_tiny_defconfig: FAIL
> > > > allnoconfig: FAIL
> > > 
> > > > Errors summary:
> > > >
> > > > 179  include/linux/sched.h:1479:35: error: field 'arch' has 
> > > > incomplete type
> > > 
> > > This comes from 09b09ab71840 ("mm, x86/mm: Make the batched unmap TLB 
> > > flush
> > > API more generic"), backported from e73ad5ff2f76d upstream.
> > > 
> > > My 10-second analysis suggests that we should backport
> > > dcc2dc45f7cf ("sched/headers, mm: Move 'struct tlbflush_unmap_batch' from
> > >  to ")
> 
> Arnd,
> 
> Yeah, I thought of picking that one but I decided not to mess around with
> where things are in v4.9, both in terms of data declaration and filenames,
> tried to keep as they look like in v4.9.
> 
> > 
> > Ugh, that's not a "straight" port at all, and will it really solve the
> > problem here?  At first glance I don't see how, but I must be missing
> > something...
> > 
> > Eduardo, any ideas here?  It's blowing up on your backported patch :(
> 
> Maybe amending the following hunk would be an easier fix
> given that the tlbflush_unmap_batch is only used within
> the CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH.
> 
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index 74c8347..0856501 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1465,7 +1465,6 @@ enum perf_event_task_context {
>  
>  #ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
>  #include 
> -#endif
>  
>  /* Track pages that require TLB flushes */
>  struct tlbflush_unmap_batch {
> @@ -1488,6 +1487,7 @@ struct tlbflush_unmap_batch {
>  */
> bool writable;
>  };
> +#endif
>  
>  struct task_struct {
>  #ifdef CONFIG_THREAD_INFO_IN_TASK
> 
> 
> That (cross)compiles fine with multi_v7_defconfig.

For now I've dropped all of these patches from the 4.9-stable queue,
they need to be reworked as we discussed on another thread.

thanks,

greg k-h

Re: stable-rc/linux-4.9.y build: 183 builds: 179 failed, 4 passed, 179 errors (v4.9.71-115-gd4b9c892aea4)

[Eduardo Valentin]

On Thu, Dec 21, 2017 at 03:49:20PM +0100, gregkh wrote:
> On Thu, Dec 21, 2017 at 12:33:45PM +0100, Arnd Bergmann wrote:
> > On Thu, Dec 21, 2017 at 12:06 PM, kernelci.org bot  
> > wrote:
> > > stable-rc/linux-4.9.y build: 183 builds: 179 failed, 4 passed, 179 errors 
> > > (v4.9.71-115-gd4b9c892aea4)
> > >
> > > Full Build Summary: 
> > > https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.71-115-gd4b9c892aea4/
> > >
> > > Tree: stable-rc
> > > Branch: linux-4.9.y
> > > Git Describe: v4.9.71-115-gd4b9c892aea4
> > > Git Commit: d4b9c892aea47e47ebc74e59533cef79f9ca30eb
> > > Git URL: 
> > > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > > Built: 4 unique architectures
> > >
> > > Build Failures Detected:
> > >
> > > arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
> > >
> > > allnoconfig: FAIL
> > > defconfig: FAIL
> > > tinyconfig: FAIL
> > >
> > > arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
> > >
> > > acs5k_defconfig: FAIL
> > > acs5k_tiny_defconfig: FAIL
> > > allnoconfig: FAIL
> > 
> > > Errors summary:
> > >
> > > 179  include/linux/sched.h:1479:35: error: field 'arch' has 
> > > incomplete type
> > 
> > This comes from 09b09ab71840 ("mm, x86/mm: Make the batched unmap TLB flush
> > API more generic"), backported from e73ad5ff2f76d upstream.
> > 
> > My 10-second analysis suggests that we should backport
> > dcc2dc45f7cf ("sched/headers, mm: Move 'struct tlbflush_unmap_batch' from
> >  to ")

Arnd,

Yeah, I thought of picking that one but I decided not to mess around with
where things are in v4.9, both in terms of data declaration and filenames,
tried to keep as they look like in v4.9.

> 
> Ugh, that's not a "straight" port at all, and will it really solve the
> problem here?  At first glance I don't see how, but I must be missing
> something...
> 
> Eduardo, any ideas here?  It's blowing up on your backported patch :(

Maybe amending the following hunk would be an easier fix
given that the tlbflush_unmap_batch is only used within
the CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH.

diff --git a/include/linux/sched.h b/include/linux/sched.h
index 74c8347..0856501 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1465,7 +1465,6 @@ enum perf_event_task_context {
 
 #ifdef CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH
 #include 
-#endif
 
 /* Track pages that require TLB flushes */
 struct tlbflush_unmap_batch {
@@ -1488,6 +1487,7 @@ struct tlbflush_unmap_batch {
 */
bool writable;
 };
+#endif
 
 struct task_struct {
 #ifdef CONFIG_THREAD_INFO_IN_TASK


That (cross)compiles fine with multi_v7_defconfig.
> 
> thanks,
> 
> greg k-h

-- 
All the best,
Eduardo Valentin

Re: stable-rc/linux-4.9.y build: 183 builds: 179 failed, 4 passed, 179 errors (v4.9.71-115-gd4b9c892aea4)

[gregkh]

On Thu, Dec 21, 2017 at 12:33:45PM +0100, Arnd Bergmann wrote:
> On Thu, Dec 21, 2017 at 12:06 PM, kernelci.org bot  wrote:
> > stable-rc/linux-4.9.y build: 183 builds: 179 failed, 4 passed, 179 errors 
> > (v4.9.71-115-gd4b9c892aea4)
> >
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.71-115-gd4b9c892aea4/
> >
> > Tree: stable-rc
> > Branch: linux-4.9.y
> > Git Describe: v4.9.71-115-gd4b9c892aea4
> > Git Commit: d4b9c892aea47e47ebc74e59533cef79f9ca30eb
> > Git URL: 
> > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Built: 4 unique architectures
> >
> > Build Failures Detected:
> >
> > arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
> >
> > allnoconfig: FAIL
> > defconfig: FAIL
> > tinyconfig: FAIL
> >
> > arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
> >
> > acs5k_defconfig: FAIL
> > acs5k_tiny_defconfig: FAIL
> > allnoconfig: FAIL
> 
> > Errors summary:
> >
> > 179  include/linux/sched.h:1479:35: error: field 'arch' has incomplete 
> > type
> 
> This comes from 09b09ab71840 ("mm, x86/mm: Make the batched unmap TLB flush
> API more generic"), backported from e73ad5ff2f76d upstream.
> 
> My 10-second analysis suggests that we should backport
> dcc2dc45f7cf ("sched/headers, mm: Move 'struct tlbflush_unmap_batch' from
>  to ")

Ugh, that's not a "straight" port at all, and will it really solve the
problem here?  At first glance I don't see how, but I must be missing
something...

Eduardo, any ideas here?  It's blowing up on your backported patch :(

thanks,

greg k-h

Re: stable-rc/linux-4.9.y build: 183 builds: 179 failed, 4 passed, 179 errors (v4.9.71-115-gd4b9c892aea4)

[Arnd Bergmann]

On Thu, Dec 21, 2017 at 12:06 PM, kernelci.org bot  wrote:
> stable-rc/linux-4.9.y build: 183 builds: 179 failed, 4 passed, 179 errors 
> (v4.9.71-115-gd4b9c892aea4)
>
> Full Build Summary: 
> https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.71-115-gd4b9c892aea4/
>
> Tree: stable-rc
> Branch: linux-4.9.y
> Git Describe: v4.9.71-115-gd4b9c892aea4
> Git Commit: d4b9c892aea47e47ebc74e59533cef79f9ca30eb
> Git URL: 
> http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Built: 4 unique architectures
>
> Build Failures Detected:
>
> arm64:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
>
> allnoconfig: FAIL
> defconfig: FAIL
> tinyconfig: FAIL
>
> arm:gcc version 5.3.1 20160412 (Linaro GCC 5.3-2016.05)
>
> acs5k_defconfig: FAIL
> acs5k_tiny_defconfig: FAIL
> allnoconfig: FAIL

> Errors summary:
>
> 179  include/linux/sched.h:1479:35: error: field 'arch' has incomplete 
> type

This comes from 09b09ab71840 ("mm, x86/mm: Make the batched unmap TLB flush
API more generic"), backported from e73ad5ff2f76d upstream.

My 10-second analysis suggests that we should backport
dcc2dc45f7cf ("sched/headers, mm: Move 'struct tlbflush_unmap_batch' from
 to ")

  Arnd

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

[Mikulas Patocka]

On Thu, 31 Aug 2017, Greg Kroah-Hartman wrote:

> On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote:
> > Hello everyone,
> > 
> > Recently Nathan March reported on centos-virt list he's getting frequent 
> > Linux kernel crashes with Linux 4.9 LTS kernel because of the missing patch 
> > "tty: Fix ldisc crash on reopened tty".
> 
> Crashes with "normal" operation, or crashes when running a fuzzer or
> other type of program?

I can crash it reliably (in a few tries), if I use an old Debian 5 
userspace on PA-RISC. The crash happens when I connect to the machine with 
ssh and type something to the terminal before the prompt appears.

Mikulas

> > The patch was already merged upstream here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05
> > 
> > but then reverted here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=896d81fefe5d1919537db2c2150ab6384e4a6610
> > 
> > Nathan confirmed if he applies the patch from 
> > 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the 
> > bug/problem goes away, so the patch (or similar fix) is still needed, at 
> > least for 4.9 LTS kernel.
> > 
> > 
> > Mikulas reported he's able to trigger the same crash on Linux 4.10:
> > https://www.spinics.net/lists/kernel/msg2440637.html
> > https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#2664604
> > 
> > Michael Neuling reported he's able to trigger the bug on PowerPC:
> > https://lkml.org/lkml/2017/3/10/1582
> > 
> > 
> > So now the question is.. is anyone currently working on getting this patch 
> > fixed and applied upstream? I think one of the problems earlier was being 
> > able to reliable reproduce the crash.. Nathan says he's able to reproduce 
> > it many times per week on his environment on x86_64.
> 
> I don't know of anyone working on it, want to do it yourself?
> 
> thanks,
> 
> greg k-h
> 

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

[Pasi Kärkkäinen]

On Thu, Aug 31, 2017 at 03:22:05PM +1000, Michael Neuling wrote:
> On Thu, 2017-08-31 at 06:36 +0200, Greg Kroah-Hartman wrote:
> > On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote:
> > > Hello everyone,
> > > 
> > > Recently Nathan March reported on centos-virt list he's getting frequent
> > > Linux kernel crashes with Linux 4.9 LTS kernel because of the missing 
> > > patch
> > > "tty: Fix ldisc crash on reopened tty".
> > 
> > Crashes with "normal" operation, or crashes when running a fuzzer or
> > other type of program?
> 
> For me it crashed on boot.
>

Nathan said he's getting the crashes at runtime, randomly, but often.

 
> > 
> > > The patch was already merged upstream here:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > > d=71472fa9c52b1da27663c275d416d8654b905f05
> > > 
> > > but then reverted here:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > > d=896d81fefe5d1919537db2c2150ab6384e4a6610
> > > 
> > > Nathan confirmed if he applies the patch from
> > > 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the
> > > bug/problem goes away, so the patch (or similar fix) is still needed, at
> > > least for 4.9 LTS kernel.
> > > 
> > > 
> > > Mikulas reported he's able to trigger the same crash on Linux 4.10:
> > > https://www.spinics.net/lists/kernel/msg2440637.html
> > > https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#26
> > > 64604
> > > 
> > > Michael Neuling reported he's able to trigger the bug on PowerPC:
> > > https://lkml.org/lkml/2017/3/10/1582
> > > 
> > > 
> > > So now the question is.. is anyone currently working on getting this patch
> > > fixed and applied upstream? I think one of the problems earlier was being
> > > able to reliable reproduce the crash.. Nathan says he's able to reproduce 
> > > it
> > > many times per week on his environment on x86_64.
> > 
> > I don't know of anyone working on it, want to do it yourself?
> 
> I'm not anymore. We found it was only triggered on a bogus CONFIG option
> combination.  Once we removed that, it no longer happened.
> 
> The underlying bug was still there though.
> 


Yep.. and the bug seems to trigger at runtime.



> Mikey


-- Pasi

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

[Michael Neuling]

On Thu, 2017-08-31 at 06:36 +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote:
> > Hello everyone,
> > 
> > Recently Nathan March reported on centos-virt list he's getting frequent
> > Linux kernel crashes with Linux 4.9 LTS kernel because of the missing patch
> > "tty: Fix ldisc crash on reopened tty".
> 
> Crashes with "normal" operation, or crashes when running a fuzzer or
> other type of program?

For me it crashed on boot.

> 
> > The patch was already merged upstream here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > d=71472fa9c52b1da27663c275d416d8654b905f05
> > 
> > but then reverted here:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i
> > d=896d81fefe5d1919537db2c2150ab6384e4a6610
> > 
> > Nathan confirmed if he applies the patch from
> > 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the
> > bug/problem goes away, so the patch (or similar fix) is still needed, at
> > least for 4.9 LTS kernel.
> > 
> > 
> > Mikulas reported he's able to trigger the same crash on Linux 4.10:
> > https://www.spinics.net/lists/kernel/msg2440637.html
> > https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#26
> > 64604
> > 
> > Michael Neuling reported he's able to trigger the bug on PowerPC:
> > https://lkml.org/lkml/2017/3/10/1582
> > 
> > 
> > So now the question is.. is anyone currently working on getting this patch
> > fixed and applied upstream? I think one of the problems earlier was being
> > able to reliable reproduce the crash.. Nathan says he's able to reproduce it
> > many times per week on his environment on x86_64.
> 
> I don't know of anyone working on it, want to do it yourself?

I'm not anymore. We found it was only triggered on a bogus CONFIG option
combination.  Once we removed that, it no longer happened.

The underlying bug was still there though.

Mikey

Re: Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

[Greg Kroah-Hartman]

On Wed, Aug 30, 2017 at 11:10:14PM +0300, Pasi Kärkkäinen wrote:
> Hello everyone,
> 
> Recently Nathan March reported on centos-virt list he's getting frequent 
> Linux kernel crashes with Linux 4.9 LTS kernel because of the missing patch 
> "tty: Fix ldisc crash on reopened tty".

Crashes with "normal" operation, or crashes when running a fuzzer or
other type of program?

> The patch was already merged upstream here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05
> 
> but then reverted here:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=896d81fefe5d1919537db2c2150ab6384e4a6610
> 
> Nathan confirmed if he applies the patch from 
> 71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the 
> bug/problem goes away, so the patch (or similar fix) is still needed, at 
> least for 4.9 LTS kernel.
> 
> 
> Mikulas reported he's able to trigger the same crash on Linux 4.10:
> https://www.spinics.net/lists/kernel/msg2440637.html
> https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#2664604
> 
> Michael Neuling reported he's able to trigger the bug on PowerPC:
> https://lkml.org/lkml/2017/3/10/1582
> 
> 
> So now the question is.. is anyone currently working on getting this patch 
> fixed and applied upstream? I think one of the problems earlier was being 
> able to reliable reproduce the crash.. Nathan says he's able to reproduce it 
> many times per week on his environment on x86_64.

I don't know of anyone working on it, want to do it yourself?

thanks,

greg k-h

Status of reverted Linux patch "tty: Fix ldisc crash on reopened tty", Linux 4.9 kernel frequent crashes

[Pasi Kärkkäinen]

Hello everyone,

Recently Nathan March reported on centos-virt list he's getting frequent Linux 
kernel crashes with Linux 4.9 LTS kernel because of the missing patch "tty: Fix 
ldisc crash on reopened tty".

The patch was already merged upstream here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71472fa9c52b1da27663c275d416d8654b905f05

but then reverted here:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=896d81fefe5d1919537db2c2150ab6384e4a6610

Nathan confirmed if he applies the patch from 
71472fa9c52b1da27663c275d416d8654b905f05 to his Linux 4.9 LTS kernel the 
bug/problem goes away, so the patch (or similar fix) is still needed, at least 
for 4.9 LTS kernel.


Mikulas reported he's able to trigger the same crash on Linux 4.10:
https://www.spinics.net/lists/kernel/msg2440637.html
https://lists.gt.net/linux/kernel/2664604?search_string=ldisc%20reopened;#2664604

Michael Neuling reported he's able to trigger the bug on PowerPC:
https://lkml.org/lkml/2017/3/10/1582


So now the question is.. is anyone currently working on getting this patch 
fixed and applied upstream? I think one of the problems earlier was being able 
to reliable reproduce the crash.. Nathan says he's able to reproduce it many 
times per week on his environment on x86_64.


Thanks a lot,

-- Pasi

Re: AMD Polaris 12 / RX 5xx support for Linux 4.9.x

[Greg KH]

On Wed, Aug 09, 2017 at 07:36:20PM +0200, Axel Rohde wrote:
> 
> Hi Kernel Maintainers,
>  
> I'm using Debian 9 ("Stretch", has just become stable) with Kernel 4.9.30.
>  
> Recently I added a AMD Radeon RX 550 (Polaris 12) graphics board to my system 
> to connect an
> Ultra HD Monitor using Display Port 1.2, which the Intel Ivy Bridge core i5 
> lacks.
>  
> Unfortunately 4.9.30 did NOT support AMD Radeon RX 550 (Polaris 12).
> I had to use kernel 4.11.
>  
> Are you planning to backport support for AMDGPU Polaris 12 (AMD Radeon RX 5xx 
> Series graphics boards)
> from 4.11 or later back to 4.9?

Note, the stable kernel trees do not add new device support to them over
the lifetime of their existance, with the exception of simple new device
ids or quirks.  See:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for a full list of what the rules are.

So, is support for these devices just a simple new device id to add?  If
so, what is the git commit id for them and I'll be glad to queue them
up.

If not, then no, the stable trees are not going to add new support for
them, sorry, just use a new kernel, what is keeping you on an old kernel
version?

thanks,

greg k-h

AMD Polaris 12 / RX 5xx support for Linux 4.9.x

[Axel Rohde]

Hi Kernel Maintainers,
 
I'm using Debian 9 ("Stretch", has just become stable) with Kernel 4.9.30.
 
Recently I added a AMD Radeon RX 550 (Polaris 12) graphics board to my system 
to connect an
Ultra HD Monitor using Display Port 1.2, which the Intel Ivy Bridge core i5 
lacks.
 
Unfortunately 4.9.30 did NOT support AMD Radeon RX 550 (Polaris 12).
I had to use kernel 4.11.
 
Are you planning to backport support for AMDGPU Polaris 12 (AMD Radeon RX 5xx 
Series graphics boards)
from 4.11 or later back to 4.9?
 
 
"Other things" include Mesa, Firmware, libdrm, xf86-video-amdgpu, which aren't 
a big deal to compile.
The kernel, however, takes 30min+ and the next lonterm kernel might not be too 
compatible to Debian 9.
 
Best regards,
   Axel Rohde
 

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

[Philipp Hahn]

Hello,

Am 18.06.2017 um 20:22 schrieb Philipp Hahn:
> Am 17.06.2017 um 18:51 schrieb Laszlo Ersek:
>> (I also recommend using the "vbindiff" tool for such problems, it is
>> great for picking out patterns.)
>>
>>   ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
>>   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
>>   01 e8 00 00 00 00 00 00  8c 5e 00 00 00 10 ff f1
>> 0010  5b 78 8a 3e 00 00 00 00  00 00 00 00 00 00 00 00
>> 0020  8c 77 00 00 00 12 00 02  18 f0 00 00 00 00 00 00
>> 0030  00 1e 00 00 00 00 00 00  8c 8c 00 00 00 12 00 02
>> 0040  07 70 00 00 00 00 00 00  00 14 00 00 00 00 00 00
>> 0050  8c 9c 00 00 00 12 00 02  22 00 00 00 00 00 00 00
>> 0060  00 40 00 00 00 00 00 00  8c ac 00 00 00 10 ff f1
>>
>>   01 e8 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>> 0010  5b 78 8a 3e 00 00 00 00  00 3c 00 00 00 07 00 00
>> 0020  8c 77 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
>> 0030  00 1e 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>> 0040  07 70 00 00 00 00 00 00  00 3c 00 00 00 07 00 00
>> 0050  8c 9c 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
>> 0060  00 40 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>>   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
>>   ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
>>
>> The columns that I marked with "**" are identical between "good" and
>> "bad". (These are columns 0-7, 10-12.)
>>
>> Column 8 is overwritten by zeros (every 16th byte).
>>
>> Column 9 is overwritten by 0x3c (every 16th byte).
>>
>> Column 13 is super interesting. The most significant nibble in that
>> column is not disturbed. And, in the least significant nibble, the least
>> significant three bits are turned on. Basically, the corruption could be
>> described, for this column (i.e., every 16th byte), as
>>
>>   bad = good | 0x7
>>
>> Column 14 is overwritten by zeros (every 16th byte).
>>
>> Column 15 is overwritten by zeros (every 16th byte).
>>
>> My take is that your host machine has faulty RAM. Please run memtest86+
>> or something similar.
> 
> I will do so, but for me very unlikely:
> - it never happens with BIOS, only with OVMF
> - for each test I start q new QEMU process, which should use a different
> memory region
> - it repeatedly hits e1000 or libata.ko

Okay: memtest+-5.01 run for 8h and did not find any errors in those 3
passes.

> After updating from OVMF to 0~20161202.7bbe0b3e-1 from
> (0~20160813.de74668f-2 it has not yet happened again.

Anyway, thank you for your help.

Philipp

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

[Philipp Hahn]

Am 18.06.2017 um 20:27 schrieb Dr. David Alan Gilbert:
> * Philipp Hahn (h...@univention.de) wrote:
>> Hello,
>>
>> Am 17.06.2017 um 18:51 schrieb Laszlo Ersek:
>>> (I also recommend using the "vbindiff" tool for such problems, it is
>>> great for picking out patterns.)
>>>
>>>   ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
>>>   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
>>>   01 e8 00 00 00 00 00 00  8c 5e 00 00 00 10 ff f1
>>> 0010  5b 78 8a 3e 00 00 00 00  00 00 00 00 00 00 00 00
>>> 0020  8c 77 00 00 00 12 00 02  18 f0 00 00 00 00 00 00
>>> 0030  00 1e 00 00 00 00 00 00  8c 8c 00 00 00 12 00 02
>>> 0040  07 70 00 00 00 00 00 00  00 14 00 00 00 00 00 00
>>> 0050  8c 9c 00 00 00 12 00 02  22 00 00 00 00 00 00 00
>>> 0060  00 40 00 00 00 00 00 00  8c ac 00 00 00 10 ff f1
>>>
>>>   01 e8 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>>> 0010  5b 78 8a 3e 00 00 00 00  00 3c 00 00 00 07 00 00
>>> 0020  8c 77 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
>>> 0030  00 1e 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>>> 0040  07 70 00 00 00 00 00 00  00 3c 00 00 00 07 00 00
>>> 0050  8c 9c 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
>>> 0060  00 40 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>>>   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
>>>   ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
>>>
>>> The columns that I marked with "**" are identical between "good" and
>>> "bad". (These are columns 0-7, 10-12.)
>>>
>>> Column 8 is overwritten by zeros (every 16th byte).
>>>
>>> Column 9 is overwritten by 0x3c (every 16th byte).
>>>
>>> Column 13 is super interesting. The most significant nibble in that
>>> column is not disturbed. And, in the least significant nibble, the least
>>> significant three bits are turned on. Basically, the corruption could be
>>> described, for this column (i.e., every 16th byte), as
>>>
>>>   bad = good | 0x7
>>>
>>> Column 14 is overwritten by zeros (every 16th byte).
>>>
>>> Column 15 is overwritten by zeros (every 16th byte).
>>>
>>> My take is that your host machine has faulty RAM. Please run memtest86+
>>> or something similar.
>>
>> I will do so, but for me very unlikely:
>> - it never happens with BIOS, only with OVMF
>> - for each test I start q new QEMU process, which should use a different
>> memory region
>> - it repeatedly hits e1000 or libata.ko
>>
>> After updating from OVMF to 0~20161202.7bbe0b3e-1 from
>> (0~20160813.de74668f-2 it has not yet happened again.
>>
>> Anyway, thank you for your help.
> 
> What host CPU are you using?

Everything is amd64:
> processor   : 3
> vendor_id   : GenuineIntel
> cpu family  : 6
> model   : 58
> model name  : Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz
> stepping: 9
> microcode   : 0x19
> cpu MHz : 2591.015
> cache size  : 3072 KB
> physical id : 0
> siblings: 4
> core id : 1
> cpu cores   : 2
> apicid  : 3
> initial apicid  : 3
> fpu : yes
> fpu_exception   : yes
> cpuid level : 13
> wp  : yes
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca 
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx 
> rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology 
> nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est 
> tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer 
> aes xsave avx f16c rdrand lahf_lm epb tpr_shadow vnmi flexpriority ept vpid 
> fsgsbase smep erms xsaveopt dtherm ida arat pln pts
> bugs:
> bogomips: 3592.75
> clflush size: 64
> cache_alignment : 64
> address sizes   : 36 bits physical, 48 bits virtual
> power management:

Philipp

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

[Dr. David Alan Gilbert]

* Philipp Hahn (h...@univention.de) wrote:
> Hello,
> 
> Am 17.06.2017 um 18:51 schrieb Laszlo Ersek:
> > (I also recommend using the "vbindiff" tool for such problems, it is
> > great for picking out patterns.)
> > 
> >   ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
> >   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
> >   01 e8 00 00 00 00 00 00  8c 5e 00 00 00 10 ff f1
> > 0010  5b 78 8a 3e 00 00 00 00  00 00 00 00 00 00 00 00
> > 0020  8c 77 00 00 00 12 00 02  18 f0 00 00 00 00 00 00
> > 0030  00 1e 00 00 00 00 00 00  8c 8c 00 00 00 12 00 02
> > 0040  07 70 00 00 00 00 00 00  00 14 00 00 00 00 00 00
> > 0050  8c 9c 00 00 00 12 00 02  22 00 00 00 00 00 00 00
> > 0060  00 40 00 00 00 00 00 00  8c ac 00 00 00 10 ff f1
> > 
> >   01 e8 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
> > 0010  5b 78 8a 3e 00 00 00 00  00 3c 00 00 00 07 00 00
> > 0020  8c 77 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
> > 0030  00 1e 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
> > 0040  07 70 00 00 00 00 00 00  00 3c 00 00 00 07 00 00
> > 0050  8c 9c 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
> > 0060  00 40 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
> >   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
> >   ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
> > 
> > The columns that I marked with "**" are identical between "good" and
> > "bad". (These are columns 0-7, 10-12.)
> > 
> > Column 8 is overwritten by zeros (every 16th byte).
> > 
> > Column 9 is overwritten by 0x3c (every 16th byte).
> > 
> > Column 13 is super interesting. The most significant nibble in that
> > column is not disturbed. And, in the least significant nibble, the least
> > significant three bits are turned on. Basically, the corruption could be
> > described, for this column (i.e., every 16th byte), as
> > 
> >   bad = good | 0x7
> > 
> > Column 14 is overwritten by zeros (every 16th byte).
> > 
> > Column 15 is overwritten by zeros (every 16th byte).
> > 
> > My take is that your host machine has faulty RAM. Please run memtest86+
> > or something similar.
> 
> I will do so, but for me very unlikely:
> - it never happens with BIOS, only with OVMF
> - for each test I start q new QEMU process, which should use a different
> memory region
> - it repeatedly hits e1000 or libata.ko
> 
> After updating from OVMF to 0~20161202.7bbe0b3e-1 from
> (0~20160813.de74668f-2 it has not yet happened again.
> 
> Anyway, thank you for your help.

What host CPU are you using?

Dave

> 
> Philipp
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert|   Running GNU/Linux   | Happy  \ 
\dave @ treblig.org |   | In Hex /
 \ _|_ http://www.treblig.org   |___/

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

[Philipp Hahn]

Hello,

Am 17.06.2017 um 18:51 schrieb Laszlo Ersek:
> (I also recommend using the "vbindiff" tool for such problems, it is
> great for picking out patterns.)
> 
>   ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
>   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
>   01 e8 00 00 00 00 00 00  8c 5e 00 00 00 10 ff f1
> 0010  5b 78 8a 3e 00 00 00 00  00 00 00 00 00 00 00 00
> 0020  8c 77 00 00 00 12 00 02  18 f0 00 00 00 00 00 00
> 0030  00 1e 00 00 00 00 00 00  8c 8c 00 00 00 12 00 02
> 0040  07 70 00 00 00 00 00 00  00 14 00 00 00 00 00 00
> 0050  8c 9c 00 00 00 12 00 02  22 00 00 00 00 00 00 00
> 0060  00 40 00 00 00 00 00 00  8c ac 00 00 00 10 ff f1
> 
>   01 e8 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
> 0010  5b 78 8a 3e 00 00 00 00  00 3c 00 00 00 07 00 00
> 0020  8c 77 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
> 0030  00 1e 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
> 0040  07 70 00 00 00 00 00 00  00 3c 00 00 00 07 00 00
> 0050  8c 9c 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
> 0060  00 40 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
>   -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
>   ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
> 
> The columns that I marked with "**" are identical between "good" and
> "bad". (These are columns 0-7, 10-12.)
> 
> Column 8 is overwritten by zeros (every 16th byte).
> 
> Column 9 is overwritten by 0x3c (every 16th byte).
> 
> Column 13 is super interesting. The most significant nibble in that
> column is not disturbed. And, in the least significant nibble, the least
> significant three bits are turned on. Basically, the corruption could be
> described, for this column (i.e., every 16th byte), as
> 
>   bad = good | 0x7
> 
> Column 14 is overwritten by zeros (every 16th byte).
> 
> Column 15 is overwritten by zeros (every 16th byte).
> 
> My take is that your host machine has faulty RAM. Please run memtest86+
> or something similar.

I will do so, but for me very unlikely:
- it never happens with BIOS, only with OVMF
- for each test I start q new QEMU process, which should use a different
memory region
- it repeatedly hits e1000 or libata.ko

After updating from OVMF to 0~20161202.7bbe0b3e-1 from
(0~20160813.de74668f-2 it has not yet happened again.

Anyway, thank you for your help.

Philipp

Re: [Qemu-devel] [RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

[Laszlo Ersek]

On 06/16/17 19:03, Philipp Hahn wrote:

> Comparing the corrupted (left) with the supposed (right) driver shows
> the following pattern:
>> /tmp/uefi.bin [+]   15038,1  Alles 
>> /tmp/uefi.ko [+]15038,1  Alles
>>   003ac00: e801    3c00  1700   <...  |  
>> 003ac00: e801    5e8c  1000 f1ff  ^...
>>   003ac10: 785b 3e8a   3c00  0700   x[>.<...  |  
>> 003ac10: 785b 3e8a        x[>.
>>   003ac20: 778c  1200 0200 3c00  0700   w...<...  |  
>> 003ac20: 778c  1200 0200 f018     w...
>>   003ac30: 1e00    3c00  1700   <...  |  
>> 003ac30: 1e00    8c8c  1200 0200  
>>   003ac40: 7007    3c00  0700   p...<...  |  
>> 003ac40: 7007    1400     p...
>>   003ac50: 9c8c  1200 0200 3c00  0700   <...  |  
>> 003ac50: 9c8c  1200 0200 0022     ."..
>>   003ac60: 4000    3c00  1700   @...<...  |  
>> 003ac60: 4000    ac8c  1000 f1ff  @...

Let me give you a different visual representation. First good, then bad.

(I also recommend using the "vbindiff" tool for such problems, it is
great for picking out patterns.)

  ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15
  -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
  01 e8 00 00 00 00 00 00  8c 5e 00 00 00 10 ff f1
0010  5b 78 8a 3e 00 00 00 00  00 00 00 00 00 00 00 00
0020  8c 77 00 00 00 12 00 02  18 f0 00 00 00 00 00 00
0030  00 1e 00 00 00 00 00 00  8c 8c 00 00 00 12 00 02
0040  07 70 00 00 00 00 00 00  00 14 00 00 00 00 00 00
0050  8c 9c 00 00 00 12 00 02  22 00 00 00 00 00 00 00
0060  00 40 00 00 00 00 00 00  8c ac 00 00 00 10 ff f1

  01 e8 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
0010  5b 78 8a 3e 00 00 00 00  00 3c 00 00 00 07 00 00
0020  8c 77 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
0030  00 1e 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
0040  07 70 00 00 00 00 00 00  00 3c 00 00 00 07 00 00
0050  8c 9c 00 00 00 12 00 02  00 3c 00 00 00 07 00 00
0060  00 40 00 00 00 00 00 00  00 3c 00 00 00 17 00 00
  -- -- -- -- -- -- -- --  -- -- -- -- -- -- -- --
  ** ** ** ** ** ** ** **   8  9 ** ** ** 13 14 15

The columns that I marked with "**" are identical between "good" and
"bad". (These are columns 0-7, 10-12.)

Column 8 is overwritten by zeros (every 16th byte).

Column 9 is overwritten by 0x3c (every 16th byte).

Column 13 is super interesting. The most significant nibble in that
column is not disturbed. And, in the least significant nibble, the least
significant three bits are turned on. Basically, the corruption could be
described, for this column (i.e., every 16th byte), as

  bad = good | 0x7

Column 14 is overwritten by zeros (every 16th byte).

Column 15 is overwritten by zeros (every 16th byte).

My take is that your host machine has faulty RAM. Please run memtest86+
or something similar.

Thanks
Laszlo

[RFH] qemu-2.6 memory corruption with OVMF and linux-4.9

[Philipp Hahn]

Hello,

I tried to get QEMU running with UEFI and SecureBoot. It sometimes
works, but sometimes I get memory corruption:
- the Debian installer sometimes fails to load the "libata.ko" or
"e1000.ko" modules.
- it it not always the same module
- my guest kernel uses KASLR, which might explain different modules
getting corrupted
- the file size is the same
- md5sums differs
- modules are all loaded from InitRamFS.
- depmod detects a cyclic dependency for "libata" on itelf:
> depmod: ERROR: Cycle detected: libata -> libata

Comparing the corrupted (left) with the supposed (right) driver shows
the following pattern:
> /tmp/uefi.bin [+]   15038,1  Alles 
> /tmp/uefi.ko [+]15038,1  Alles
>   003ac00: e801    3c00  1700   <...  |  
> 003ac00: e801    5e8c  1000 f1ff  ^...  
>   003ac10: 785b 3e8a   3c00  0700   x[>.<...  |  
> 003ac10: 785b 3e8a        x[>.  
>   003ac20: 778c  1200 0200 3c00  0700   w...<...  |  
> 003ac20: 778c  1200 0200 f018     w...  
>   003ac30: 1e00    3c00  1700   <...  |  
> 003ac30: 1e00    8c8c  1200 0200    
>   003ac40: 7007    3c00  0700   p...<...  |  
> 003ac40: 7007    1400     p...  
>   003ac50: 9c8c  1200 0200 3c00  0700   <...  |  
> 003ac50: 9c8c  1200 0200 0022     ."..  
>   003ac60: 4000    3c00  1700   @...<...  |  
> 003ac60: 4000    ac8c  1000 f1ff  @...  

That's the only difference in the 433702 byte sized file. (libata.ko)

I suspect this to be frame-buffer related, as the EFI frame-buffer is
also broken: see attached screen-shot
> # dmesg
> [0.980927] efifb: probing for efifb
> [0.981656] efifb: framebuffer at 0x8000, using 1876k, total 1875k
> [0.983030] efifb: mode is 800x600x32, linelength=3200, pages=1
> [0.984293] efifb: scrolling: redraw
> [0.985128] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
> [0.988296] Console: switching to colour frame buffer device 100x37
> [0.990700] fb0: EFI VGA frame buffer device

My host system is a Debian-Jessie system with newer QEMU components:
> $ dpkg-query -W qemu-system-x86 ovmf linux-image-4.9\*
> linux-image-4.9.0-0.bpo.3-amd64 4.9.25-1~bpo8+1
> ovmf0~20160813.de74668f-2
> qemu-system-x86 1:2.6+dfsg-3.1~bpo8+1

My guest uses linux-4.9.13 self-compiled:
> CONFIG_RANDOMIZE_BASE=y
> CONFIG_RANDOMIZE_MEMORY=y
> CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
> CONFIG_FB_EFI=y
> CONFIG_FRAMEBUFFER_CONSOLE=y
> CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
> CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y

Bootloder is GRUB2, which initialized the frame-buffer to 800x600

QEMU is launched through libvirt:
> qemu-system-x86_64 -enable-kvm -name uefi -S -machine 
> pc-i440fx-2.1,accel=kvm,usb=off -drive 
> file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on 
> -drive 
> file=/var/lib/libvirt/qemu/nvram/uefi_VARS.fd,if=pflash,format=raw,unit=1 -m 
> 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 
> 1d33ad46-5325-4bf0-b87f-e897b8b66946 -no-user-config -nodefaults -chardev 
> socket,id=charmonitor,path=/home/phahn/.config/libvirt/qemu/lib/uefi.monitor,server,nowait
>  -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
> -global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global 
> PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device 
> ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x5.0x7 -device 
> ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x5
>  -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x5.0x1 
> -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x5.0x2 
> -device lsi,id=scsi0,bus=pci.0,addr=0x6 -device 
> ahci,id=ahci0,bus=pci.0,addr=0x7 -drive 
> file=/home/libvirt/ucs_4.2-0-latest-amd64.iso,format=raw,if=none,media=cdrom,id=drive-sata0-0-0,readonly=on
>  -device ide-cd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0,bootindex=1 
> -drive 
> file=/home/libvirt/UEFI.qcow2,format=qcow2,if=none,id=drive-sata0-0-1,cache=unsafe,discard=unmap
>  -device ide-hd,bus=ahci0.1,drive=drive-sata0-0-1,id=sata0-0-1,bootindex=2 
> -netdev tap,fd=23,id=hostnet0 -device 
> e1000,netdev=hostnet0,id=net0,mac=52:54:00:31:e6:b4,bus=pci.0,addr=0x3 
> -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
> -chardev file,id=charserial1,path=/tmp/uefi.log -device 
> isa-serial,chardev=charserial1,id=serial1 -vnc 127.0.0.1:0 -device 
> cirrus-vga,id=video0,bus=pci.0,addr=0x2 -device 
> intel-hda,id=sound0,bus=pci.0,addr=0x4 -device 
> hda-duplex,id=sound0-codec0,bus=sound0.

Re: stable-rc/linux-4.9.y build: 203 builds: 12 failed, 191 passed, 12 errors, 4 warnings (v4.9.31-86-gaa17912d6233)

[gregkh]

On Mon, Jun 12, 2017 at 01:18:55PM +0200, Arnd Bergmann wrote:
> On Mon, Jun 12, 2017 at 12:16 PM, kernelci.org bot  wrote:
> > stable-rc/linux-4.9.y build: 203 builds: 12 failed, 191 passed, 12 errors, 
> > 4 warnings (v4.9.31-86-gaa17912d6233)
> >
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.31-86-gaa17912d6233/
> >
> > Tree: stable-rc
> > Branch: linux-4.9.y
> > Git Describe: v4.9.31-86-gaa17912d6233
> > Git Commit: aa17912d62333ce082f4fbf7b1727b7ff7694e79
> > Git URL: 
> > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Built: 4 unique architectures
> >
> > Build Failures Detected:
> >
> > mips:gcc version 6.3.0 (GCC)
> >
> > decstation_defconfig: FAIL
> > defconfig+CONFIG_LKDTM=y: FAIL
> > ip22_defconfig: FAIL
> > jazz_defconfig: FAIL
> > malta_defconfig: FAIL
> > malta_kvm_defconfig: FAIL
> > malta_kvm_guest_defconfig: FAIL
> > maltaup_xpa_defconfig: FAIL
> > nlm_xlp_defconfig: FAIL
> > nlm_xlr_defconfig: FAIL
> > rm200_defconfig: FAIL
> >
> > x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
> >
> > allmodconfig+CONFIG_OF=n: FAIL
> >
> 
> > Errors summary:
> >
> >  12  fs/ufs/balloc.c:501:26: error: implicit declaration of function 
> > 'i_blocksize' [-Werror=implicit-function-declaration]
> 
> Caused by the backport of eb315d2ae614 ("ufs: restore maintaining 
> ->i_blocks"):
> We also need a backport of 93407472a21b ("fs: add i_blocksize()")
> to address this, at least the hunk in include/linux/fs.h.

Should now be fixed.

thanks,

greg k-h

Re: stable-rc/linux-4.9.y build: 203 builds: 12 failed, 191 passed, 12 errors, 4 warnings (v4.9.31-86-gaa17912d6233)

[gregkh]

On Mon, Jun 12, 2017 at 01:18:55PM +0200, Arnd Bergmann wrote:
> On Mon, Jun 12, 2017 at 12:16 PM, kernelci.org bot  wrote:
> > stable-rc/linux-4.9.y build: 203 builds: 12 failed, 191 passed, 12 errors, 
> > 4 warnings (v4.9.31-86-gaa17912d6233)
> >
> > Full Build Summary: 
> > https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.31-86-gaa17912d6233/
> >
> > Tree: stable-rc
> > Branch: linux-4.9.y
> > Git Describe: v4.9.31-86-gaa17912d6233
> > Git Commit: aa17912d62333ce082f4fbf7b1727b7ff7694e79
> > Git URL: 
> > http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> > Built: 4 unique architectures
> >
> > Build Failures Detected:
> >
> > mips:gcc version 6.3.0 (GCC)
> >
> > decstation_defconfig: FAIL
> > defconfig+CONFIG_LKDTM=y: FAIL
> > ip22_defconfig: FAIL
> > jazz_defconfig: FAIL
> > malta_defconfig: FAIL
> > malta_kvm_defconfig: FAIL
> > malta_kvm_guest_defconfig: FAIL
> > maltaup_xpa_defconfig: FAIL
> > nlm_xlp_defconfig: FAIL
> > nlm_xlr_defconfig: FAIL
> > rm200_defconfig: FAIL
> >
> > x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
> >
> > allmodconfig+CONFIG_OF=n: FAIL
> >
> 
> > Errors summary:
> >
> >  12  fs/ufs/balloc.c:501:26: error: implicit declaration of function 
> > 'i_blocksize' [-Werror=implicit-function-declaration]
> 
> Caused by the backport of eb315d2ae614 ("ufs: restore maintaining 
> ->i_blocks"):
> We also need a backport of 93407472a21b ("fs: add i_blocksize()")
> to address this, at least the hunk in include/linux/fs.h.

Hey, that was fast!

My build system just caught up to this, and yes, I'm working on the
backport right now.  Same goes for 4.4...

thanks,

greg k-h

Re: stable-rc/linux-4.9.y build: 203 builds: 12 failed, 191 passed, 12 errors, 4 warnings (v4.9.31-86-gaa17912d6233)

[Arnd Bergmann]

On Mon, Jun 12, 2017 at 12:16 PM, kernelci.org bot  wrote:
> stable-rc/linux-4.9.y build: 203 builds: 12 failed, 191 passed, 12 errors, 4 
> warnings (v4.9.31-86-gaa17912d6233)
>
> Full Build Summary: 
> https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.31-86-gaa17912d6233/
>
> Tree: stable-rc
> Branch: linux-4.9.y
> Git Describe: v4.9.31-86-gaa17912d6233
> Git Commit: aa17912d62333ce082f4fbf7b1727b7ff7694e79
> Git URL: 
> http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> Built: 4 unique architectures
>
> Build Failures Detected:
>
> mips:gcc version 6.3.0 (GCC)
>
> decstation_defconfig: FAIL
> defconfig+CONFIG_LKDTM=y: FAIL
> ip22_defconfig: FAIL
> jazz_defconfig: FAIL
> malta_defconfig: FAIL
> malta_kvm_defconfig: FAIL
> malta_kvm_guest_defconfig: FAIL
> maltaup_xpa_defconfig: FAIL
> nlm_xlp_defconfig: FAIL
> nlm_xlr_defconfig: FAIL
> rm200_defconfig: FAIL
>
> x86:gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4)
>
> allmodconfig+CONFIG_OF=n: FAIL
>

> Errors summary:
>
>  12  fs/ufs/balloc.c:501:26: error: implicit declaration of function 
> 'i_blocksize' [-Werror=implicit-function-declaration]

Caused by the backport of eb315d2ae614 ("ufs: restore maintaining ->i_blocks"):
We also need a backport of 93407472a21b ("fs: add i_blocksize()")
to address this, at least the hunk in include/linux/fs.h.

Arnd

Regression - Linux 4.9: ums_eneub6250 broken: transfer buffer not dma capable - Trace

[Andreas Hartmann]

Hello!

Since Linux 4.9, ums_eneub6250 is broken. It's working fine if
CONFIG_VMAP_STACK is disabled.

I would be glad if it would be fixed.


Thanks,
kind regards,
Andreas


Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: new high-speed USB device number 3 
using ehci-pci
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: New USB device found, 
idVendor=0cf2, idProduct=6250
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: New USB device strings: Mfr=1, 
Product=2, SerialNumber=4
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: Product: UB6250   
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: Manufacturer: ENE Flash  
Apr 15 17:58:54 notebook2 kernel: usb 1-1.1: SerialNumber: 606569746801
Apr 15 17:58:54 notebook2 mtp-probe[2134]: checking bus 1, device 3: 
"/sys/devices/pci:00/:00:1a.0/usb1/1-1/1-1.1"
Apr 15 17:58:54 notebook2 mtp-probe[2134]: bus: 1, device: 3 was not an MTP 
device
Apr 15 17:58:55 notebook2 kernel: usbcore: registered new interface driver 
usb-storage
Apr 15 17:58:55 notebook2 kernel: usbcore: registered new interface driver uas
Apr 15 17:58:55 notebook2 kernel: ums_eneub6250 1-1.1:1.0: USB Mass Storage 
device detected
Apr 15 17:58:55 notebook2 kernel: scsi host6: usb-storage 1-1.1:1.0
Apr 15 17:58:55 notebook2 kernel: [ cut here ]
Apr 15 17:58:55 notebook2 kernel: WARNING: CPU: 2 PID: 2133 at 
../drivers/usb/core/hcd.c:1587 usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel: transfer buffer not dma capable
Apr 15 17:58:55 notebook2 kernel: Modules linked in: ums_eneub6250(+) uas 
usb_storage fuse binfmt_misc snd_hda_codec_hdmi snd_hda_codec_realtek 
snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hda_core snd_hwdep 
snd_pcm_oss msi_wmi iTCO_wdt iTCO_vendor_support snd_pcm wmi snd_seq battery ac 
msi_laptop sparse_keymap rfkill joydev snd_seq_device snd_timer r8169 mii 
snd_mixer_oss intel_powerclamp coretemp kvm_intel snd mei_me mei kvm i2c_i801 
lpc_ich soundcore intel_ips shpchp mfd_core i2c_smbus fjes acpi_cpufreq tpm_tis 
pcspkr thermal tpm_tis_core tpm irqbypass fan dm_crypt crc32c_intel serio_raw 
sr_mod cdrom ehci_pci i915 ehci_hcd i2c_algo_bit usbcore drm_kms_helper 
syscopyarea sysfillrect sysimgblt fb_sys_fops drm video button dm_mirror 
dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc 
scsi_dh_alua
Apr 15 17:58:55 notebook2 kernel: CPU: 2 PID: 2133 Comm: systemd-udevd Not 
tainted 4.9.21-1-default #1
Apr 15 17:58:55 notebook2 kernel: Hardware name: Micro-Star International 
CR620/CR620, BIOS E1681IMS VER.10C 04/12/2011
Apr 15 17:58:55 notebook2 kernel:  baf681b477f0 af3c854a 
baf681b47840 
Apr 15 17:58:55 notebook2 kernel:  baf681b47830 af085c71 
0633af0bd0de 8d35b2844e40
Apr 15 17:58:55 notebook2 kernel:   0200 
0002 8d360fafd800
Apr 15 17:58:55 notebook2 kernel: Call Trace:
Apr 15 17:58:55 notebook2 kernel:  [] dump_stack+0x63/0x89
Apr 15 17:58:55 notebook2 kernel:  [] __warn+0xd1/0xf0
Apr 15 17:58:55 notebook2 kernel:  [] 
warn_slowpath_fmt+0x4f/0x60
Apr 15 17:58:55 notebook2 kernel:  [] ? 
put_prev_entity+0x48/0x720
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_hcd_map_urb_for_dma+0x4ba/0x4f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? 
finish_task_switch+0x78/0x1e0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_hcd_submit_urb+0x1c9/0xb30 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? schedule+0x3d/0x90
Apr 15 17:58:55 notebook2 kernel:  [] ? 
schedule_timeout+0x220/0x3c0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_submit_urb.part.6+0x295/0x550 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_submit_urb+0x34/0x70 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_msg_common+0x9d/0x120 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_bulk_transfer_buf+0x56/0xa0 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_stor_bulk_transfer_sg+0x4e/0x60 [usb_storage]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_send_scsi_cmd+0x97/0x160 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_get_card_type.constprop.19+0x5b/0x60 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_ub6250_probe+0x8f/0x110 [ums_eneub6250]
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_probe_interface+0x157/0x2f0 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] 
driver_probe_device+0x227/0x440
Apr 15 17:58:55 notebook2 kernel:  [] 
__driver_attach+0xdd/0xe0
Apr 15 17:58:55 notebook2 kernel:  [] ? 
driver_probe_device+0x440/0x440
Apr 15 17:58:55 notebook2 kernel:  [] 
bus_for_each_dev+0x5d/0x90
Apr 15 17:58:55 notebook2 kernel:  [] driver_attach+0x1e/0x20
Apr 15 17:58:55 notebook2 kernel:  [] 
bus_add_driver+0x45/0x270
Apr 15 17:58:55 notebook2 kernel:  [] 
driver_register+0x60/0xe0
Apr 15 17:58:55 notebook2 kernel:  [] 
usb_register_driver+0x82/0x150 [usbcore]
Apr 15 17:58:55 notebook2 kernel:  [] ? 0xc03b9000
Apr 15 17:58:55 notebook2 kernel:  [] 
ene_ub6250_driver_init+0x38/0x1000

Re: Linux 4.9: libceph: use BUG() instead of BUG_ON(1)

[Greg Kroah-Hartman]

On Sun, Mar 12, 2017 at 08:38:24PM +0100, Heinrich Schuchardt wrote:
> Dear Greg,
> 
> could you, please, consider the following patch for the next Linux 4.9
> release to avoid a build failure with gcc 4.9:
> 
> d24cdcd3e40a6825135498e11c20c7976b9bf545
> libceph: use BUG() instead of BUG_ON(1)

What about for 4.10-stable as well?  It would need it too?

And ugh, you really should update your version of gcc...

thanks,

greg k-h

Linux 4.9: libceph: use BUG() instead of BUG_ON(1)

[Heinrich Schuchardt]

Dear Greg,

could you, please, consider the following patch for the next Linux 4.9
release to avoid a build failure with gcc 4.9:

d24cdcd3e40a6825135498e11c20c7976b9bf545
libceph: use BUG() instead of BUG_ON(1)

Best regards

Heinrich Schuchardt

Re: linux 4.9 breaks pctv452e

[Greg KH]

On Fri, Jan 13, 2017 at 12:15:05PM +0100, Wolfgang Rohdewald wrote:
> this OOPS always happens with 4.9. up to 4.9.3
> 
> all 4.8.x versions work fine.

Ick.  Any chance you can use 'git bisect' to determine which commit
broke this for you?

thanks,

greg k-h

linux 4.9 breaks pctv452e

[Wolfgang Rohdewald]

this OOPS always happens with 4.9. up to 4.9.3

all 4.8.x versions work fine.

Disabling VMAP_STACK does not fix it.


[9.043616] dvb-usb: found a 'Technotrend TT Connect S2-3600' in warm state.
[9.043619] pctv452e: pctv452e_power_ctrl: 1

[9.051329] BUG: unable to handle kernel NULL pointer dereference at 
  (null)
[9.051342] IP: [] __mutex_lock_slowpath+0x76/0x130
[9.051350] PGD 0 

[9.051355] Oops: 0002 [#1] PREEMPT SMP
[9.051358] Modules linked in: dvb_usb_pctv452e(+) ttpci_eeprom dvb_usb 
ftdi_sio dvb_core usbserial rc_core snd_hda_codec_hdmi(+) x86_pkg_temp_thermal 
intel_powercla
mp coretemp kvm_intel kvm irqbypass snd_hda_intel crct10dif_pclmul 
snd_hda_codec crc32_pclmul ghash_clmulni_intel snd_hda_core snd_hwdep 
aesni_intel aes_x86_64 snd_pcm 
lrw gf128mul glue_helper ablk_helper cryptd serio_raw snd_seq_midi 
snd_seq_midi_event snd_rawmidi joydev snd_seq snd_seq_device snd_timer snd 
soundcore sg mei_me mei sh
pchp lpc_ich tpm_tis tpm_tis_core nfsd auth_rpcgss nfs_acl lockd grace sunrpc 
ip_tables x_tables autofs4 usb_storage hid_generic hid_logitech_hidpp 
hid_logitech_dj usbh
id hid sd_mod nouveau e1000e psmouse ahci wmi ptp libahci ttm pps_core video
[9.051451] CPU: 4 PID: 478 Comm: systemd-udevd Not tainted 4.9.0 #1
[9.051455] Hardware name:  /DH87RL, BIOS 
RLH8710H.86A.0323.2013.1204.1726 12/04/2013
[9.051459] task: 88021156d880 task.stack: c9000171c000
[9.051462] RIP: 0010:[]  [] 
__mutex_lock_slowpath+0x76/0x130
[9.051469] RSP: 0018:c9000171fa20  EFLAGS: 00010282
[9.051472] RAX:  RBX: 8802003a7758 RCX: 0001
[9.051475] RDX: 0001 RSI: 81a771a2 RDI: 0001
[9.051479] RBP: c9000171fa68 R08: 00021b803ec5 R09: 0002
[9.051482] R10: 1329 R11: 880214cf1e00 R12: 8802003a775c
[9.051486] R13: 88021156d880 R14:  R15: 8802003a7760
[9.051490] FS:  7f6cf14748c0() GS:88021ed0() 
knlGS:
[9.051494] CS:  0010 DS:  ES:  CR0: 80050033
[9.051497] CR2:  CR3: 000214bc4000 CR4: 001406e0
[9.051500] Stack:
[9.051503]  8802003a7760  88020018 
c9000171fa90
[9.051509]  8802003a7758 88021260e900 88021273c000 
8802003a7758
[9.051516]  a0634f80 c9000171fa80 8179c507 
8802003a7700
[9.051522] Call Trace:
[9.051527]  [] mutex_lock+0x17/0x30
[9.051531]  [] pctv452e_power_ctrl+0x85/0x190 
[dvb_usb_pctv452e]
[9.051536]  [] dvb_usb_device_power_ctrl+0x3f/0x50 
[dvb_usb]
[9.051541]  [] dvb_usb_device_init+0x225/0x620 [dvb_usb]
[9.051546]  [] pctv452e_usb_probe+0x51/0x60 
[dvb_usb_pctv452e]
[9.051550]  [] usb_probe_interface+0x159/0x2d0
[9.051555]  [] driver_probe_device+0x223/0x430
[9.051559]  [] __driver_attach+0xdf/0xf0
[9.051563]  [] ? driver_probe_device+0x430/0x430
[9.051567]  [] bus_for_each_dev+0x60/0xa0
[9.051571]  [] driver_attach+0x1e/0x20
[9.051575]  [] bus_add_driver+0x170/0x270
[9.051579]  [] driver_register+0x60/0xe0
[9.051583]  [] usb_register_driver+0x81/0x140
[9.051587]  [] ? 0xa03aa000
[9.051591]  [] pctv452e_usb_driver_init+0x1e/0x1000 
[dvb_usb_pctv452e]
[9.051596]  [] do_one_initcall+0x3d/0x150
[9.051601]  [] do_init_module+0x5f/0x1ef
[9.051606]  [] load_module+0x2384/0x2a40
[9.051610]  [] ? ref_module+0x190/0x190
[9.051614]  [] ? kernel_read_file+0x1a3/0x1c0
[9.051620]  [] SYSC_finit_module+0xbc/0xf0
[9.051624]  [] SyS_finit_module+0xe/0x10
[9.051628]  [] entry_SYSCALL_64_fastpath+0x1e/0xad
[9.051631] Code: e8 90 32 00 00 8b 03 83 f8 01 0f 84 b2 00 00 00 48 8b 43 
10 4c 8d 7b 08 48 89 63 10 41 be ff ff ff ff 4c 89 3c 24 48 89 44 24 08 <48> 89 
20 4c 89 6c 24 10 eb 1d 4c 89 e7 49 c7 45 08 02 00 00 00 
[9.051693] RIP  [] __mutex_lock_slowpath+0x76/0x130
[9.051698]  RSP 
[9.051700] CR2: 
[9.056544] ---[ end trace d7fca26bbd239b35 ]---

-- 
Wolfgang

Re: Note on 4.10 merge window timing (was Re: Linux 4.9-rc8)

[Al Viro]

On Wed, Dec 07, 2016 at 05:07:15PM -0800, Linus Torvalds wrote:
> On Wed, Dec 7, 2016 at 4:04 PM, Al Viro  wrote:
> >
> > Could you run this just before cutting 4.10-rc1?
> 
> Sure. I hope you'll remind me just in case, though.

Doing so...  Conversion in question is done by 

PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*'
sed -i -e "s!$PATT!#include !" \
`git grep -l "$PATT"|grep -v ^include/linux/uaccess.h`

I'd done that right now and pushed the result into vfs.git#uaccess-example;
probably would be better if you ran the above just before the -rc1.

The only place that should pull asm/uaccess.h is linux/uaccess.h.  Everything
else can include  instead.

Re: Linux 4.9-rc6

[Eric Dumazet]

On Sun, 2016-12-04 at 09:17 -0800, Eric Dumazet wrote:
> On Sun, 2016-12-04 at 03:10 -0800, Linus Torvalds wrote:
> > 
> > 
> > On Dec 4, 2016 02:43, "Thorsten Leemhuis" 
> > wrote:
> > 
> > 
> > What the status of below patch? From the discussion it looks a
> > lot like
> > it was developed to fix a regression in 4.9, but the patch
> > afaics has
> > neither his mainline or linux-next yet. 
> > 
> > 
> > It's not a regression as far as I can tell. It's a small optimization.
> > Maybe.
> > 
> > 
> > It's not going into 4.9, is not even clear it's worth it later either,
> > unless somebody had numbers (which I haven't seen)
> > 
> Right, the patch was not in anyway ready for 4.9 ;)
> 
> I'll try to complete this for next cycle.

I now have a hacky patch that also adds PMD alignment for large
allocations, and support hugepages (this last part depends on
CONFIG_HAVE_ARCH_HUGE_VMAP at this moment, x86/arm64 so far)

Toshi Kani added pmd_set_huge() in commit e61ce6ade404e ("mm: change
ioremap to set up huge I/O mappings"), I am not sure why vmalloc() was
not considered (or I might have missed it completely)

It seems to provide about 25 cycles gain per random access for large
tables on my x86 lab hosts.

(I did a test with a program having 10 Million fds)

For allocations above 2 MB (pages >= 512), like Dentry cache,
Inode-cache, TCP established hash table, or large alloc_fdmem() ones,
might benefit from this.

lpaa23:~# grep large /proc/vmallocinfo 
0xc9009000-0xc900c000   12288 
alloc_large_system_hash+0x189/0x253 pages=2 vmalloc N0=1 N1=1
0xc900c000-0xc900f000   12288 
alloc_large_system_hash+0x189/0x253 pages=2 vmalloc N0=1 N1=1
0xc901e000-0xc909f000  528384 
alloc_large_system_hash+0x189/0x253 pages=128 vmalloc N0=64 N1=64
0xc909f000-0xc90e  266240 
alloc_large_system_hash+0x189/0x253 pages=64 vmalloc N0=32 N1=32
0xc91d9000-0xc91dc000   12288 
alloc_large_system_hash+0x189/0x253 pages=2 vmalloc N0=1 N1=1
0xc920-0xc90010201000 268439552 
alloc_large_system_hash+0x189/0x253 pages=65536 vmalloc vpages N0=32768 N1=32768
0xc9001040-0xc90018401000 134221824 
alloc_large_system_hash+0x189/0x253 pages=32768 vmalloc vpages N0=16384 N1=16384
0xc9001860-0xc90018a01000 4198400 
alloc_large_system_hash+0x189/0x253 pages=1024 vmalloc vpages N0=512 N1=512
0xc90018c0-0xc90019001000 4198400 
alloc_large_system_hash+0x189/0x253 pages=1024 vmalloc vpages N0=512 N1=512
0xc9001b249000-0xc9001b34a000 1052672 
alloc_large_system_hash+0x189/0x253 pages=256 vmalloc N0=128 N1=128
0xc9001b40-0xc9001b801000 4198400 
alloc_large_system_hash+0x189/0x253 pages=1024 vmalloc vpages N0=512 N1=512
0xc9001ba0-0xc9001bc01000 2101248 
alloc_large_system_hash+0x189/0x253 pages=512 vmalloc N0=256 N1=256
0xc9001bc01000-0xc9001bd02000 1052672 
alloc_large_system_hash+0x189/0x253 pages=256 vmalloc N0=128 N1=128
0xc9001be0-0xc9001c001000 2101248 
alloc_large_system_hash+0x189/0x253 pages=512 vmalloc N0=256 N1=256


I wont be able to split this patch in 3 parts before January 6th, after
my vacations. I am showing the WIP if anyone is interested seeing this.

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index a5584384eabc..055b027ee659 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -154,6 +155,18 @@ static int vmap_pmd_range(pud_t *pud, unsigned long addr,
return -ENOMEM;
do {
next = pmd_addr_end(addr, end);
+#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
+   if (next - addr == PMD_SIZE) {
+   struct page *page = pages[*nr];
+
+   if (compound_order(page) == PMD_SHIFT - PAGE_SHIFT) {
+   if (pmd_set_huge(pmd, page_to_phys(page), 
prot)) {
+   (*nr) += 1 << (PMD_SHIFT - PAGE_SHIFT);
+   continue;
+   }
+   }
+   }
+#endif
if (vmap_pte_range(pmd, addr, next, prot, pages, nr))
return -ENOMEM;
} while (pmd++, addr = next, addr != end);
@@ -1349,7 +1362,8 @@ static struct vm_struct *__get_vm_area_node(unsigned long 
size,
if (flags & VM_IOREMAP)
align = 1ul << clamp_t(int, get_count_order_long(size),
   PAGE_SHIFT, IOREMAP_MAX_ORDER);
-
+   else if (size >= PMD_SIZE)
+   align = PMD_SIZE;
area = kzalloc_node(sizeof(*area), gfp_mask & GFP_RECLAIM_MASK, node);
if (unlikely(!area))
return NULL;
@@ -1482,11 +1496,14 @@ static void __vunmap(const void *addr, int 
deallocate_pages)
if (deallocate_pages) {
int i;
 
-  

[ANNOUNCE] linux-4.9-ck1

[Con Kolivas]

These are patches designed to improve system responsiveness and interactivity 
with specific emphasis on the desktop, but configurable for any workload. The 
patchset is mainly centred around the Multiple Queue Skiplist Scheduler, 
MuQSS.


-ck1 patches:
http://ck.kolivas.org/patches/4.0/4.9/4.9-ck1/

Git tree:
https://github.com/ckolivas/linux/tree/4.9-ck

Ubuntu 16.04 LTS packages:
http://ck.kolivas.org/patches/4.0/4.9/4.9-ck1/Ubuntu16.04/


Full patch list:

0001-Multiple-Queue-Skiplist-Scheduler-version-0.15.patch
0002-Make-preemptible-kernel-default.patch
0003-Expose-vmsplit-option-for-our-poor-32bit-users.patch
0004-Implement-min-and-msec-hrtimeout-un-interruptible-sc.patch
0005-Special-case-calls-of-schedule_timeout-1-to-use-the-.patch
0006-Convert-msleep-to-use-hrtimers-when-active.patch
0007-Replace-all-schedule_timeout-1-with-schedule_min_hrt.patch
0008-Change-all-schedule_timeout-with-msecs_to_jiffies-po.patch
0009-Replace-all-calls-to-schedule_timeout_interruptible-.patch
0010-Replace-all-calls-to-schedule_timeout_uninterruptibl.patch
0011-Fix-build-for-disabled-highres-timers-with-hrtimeout.patch
0012-Make-hrtimer-granularity-and-minimum-hrtimeout-confi.patch
0013-Make-threaded-IRQs-optionally-the-default-which-can-.patch
0014-Reinstate-default-Hz-of-100-in-combination-with-MuQS.patch
0015-Don-t-use-hrtimer-overlay-when-pm_freezing-since-som.patch
0016-wb-buf-throttle-v7.patch
0017-4.9-bfq-v8.patch
0018-Make-writeback-throttling-default-enabled.patch
0019-Add-ck1-version.patch


For a brief description of each patch without trawling the git tree, each 
patch can be found as a quilt series here:
http://ck.kolivas.org/patches/4.0/4.9/4.9-ck1/patches/


Hacking blog:
http://ck-hack.blogspot.com/

Simple homepage:
http://kernel.kolivas.org


Enjoy!
お楽しみ下さい
-- 
-ck

[ANNOUNCE] MuQSS CPU scheduler v0.15 for linux-4.9

[Con Kolivas]

Announcing an updated stable version of the Multiple Queue Skiplist Scheduler, 
the successor to BFS, version 0.150 for linux-4.9.

Download:
http://ck.kolivas.org/patches/muqss/4.0/4.9/4.9-sched-MuQSS_150.patch

Git tree:
https://github.com/ckolivas/linux/tree/4.9-muqss

--- 

Patch summary:

The MuQSS (Multiple Queue Skiplist Scheduler - pronounced mux) v0.150 by
Con Kolivas.

This is a multiple runqueue skiplist evolution of the Brain Fuck Scheduler,
designed to provide excellent latency, throughput and scalability to any
number of CPUs, with primary emphasis on latency for interactivity and
responsiveness.

A multiple runqueue strict fairness earliest effective virtual deadline first
design.

Runqueue insertion is O(log(n)), lookup is O(1), removal is amortised O(1).

Interactive mode is enabled by default but can be disabled for improved
throughput at the expense of deterministic low latency.

echo 0 > /proc/sys/kernel/interactive

Features SCHED_IDLEPRIO and SCHED_ISO scheduling policies as well.
You do NOT need to use these policies for good performance, they are purely
optional for even better performance in extreme conditions.

To run something idleprio, use schedtool like so:

schedtool -D -e make -j4

To run something isoprio, use schedtool like so:

schedtool -I -e amarok

Includes configurable SMT-nice support for better nice level and scheduling
policy support across SMT (aka hyperthread) sibling CPUs.

Includes accurate sub-tick accounting of tasks so userspace reported
cpu usage may be very different if you have very short lived tasks.

-ck

>From 0ce996c80e2c547e8bc9cfb23f028d80f34a5210 Mon Sep 17 00:00:00 2001
From: Con Kolivas 
Date: Sat, 10 Dec 2016 13:37:55 +1100
Subject: [PATCH 01/19] Multiple Queue Skiplist Scheduler version 0.15

---
 Documentation/scheduler/sched-BFS.txt |  351 ++
 Documentation/scheduler/sched-MuQSS.txt   |  345 ++
 Documentation/sysctl/kernel.txt   |   37 +
 arch/powerpc/platforms/cell/spufs/sched.c |5 -
 arch/x86/Kconfig  |   18 +-
 fs/proc/base.c|2 +-
 include/linux/init_task.h |   76 +-
 include/linux/ioprio.h|2 +
 include/linux/sched.h |   69 +-
 include/linux/sched/prio.h|   12 +
 include/linux/skip_list.h |   33 +
 include/uapi/linux/sched.h|9 +-
 init/Kconfig  |   25 +-
 init/main.c   |3 +-
 kernel/Makefile   |2 +-
 kernel/delayacct.c|2 +-
 kernel/exit.c |2 +-
 kernel/kthread.c  |   30 +-
 kernel/sched/Makefile |   13 +-
 kernel/sched/MuQSS.c  | 8033 
+
 kernel/sched/MuQSS.h  |  348 ++
 kernel/sched/cpufreq.c|4 +
 kernel/sched/cpufreq_schedutil.c  |   16 +
 kernel/sched/cputime.c|   27 +-
 kernel/sched/idle.c   |   14 +-
 kernel/sched/sched.h  |   25 +
 kernel/sched/stats.c  |4 +
 kernel/skip_list.c|  148 +
 kernel/sysctl.c   |   52 +-
 kernel/time/clockevents.c |5 +
 kernel/time/posix-cpu-timers.c|   10 +-
 kernel/time/timer.c   |7 +-
 kernel/trace/trace_selftest.c |5 +
 33 files changed, 9670 insertions(+), 64 deletions(-)
 create mode 100644 Documentation/scheduler/sched-BFS.txt
 create mode 100644 Documentation/scheduler/sched-MuQSS.txt
 create mode 100644 include/linux/skip_list.h
 create mode 100644 kernel/sched/MuQSS.c
 create mode 100644 kernel/sched/MuQSS.h
 create mode 100644 kernel/skip_list.c

-- 
-ck

Linux 4.9

[Linus Torvalds]

So Linux 4.9 is out, and the merge window for 4.10 is thus open.

With the extra week for 4.9, the timing for the merge window is
obviously a bit awkward, and it technically closes in two weeks on
Christmas Day. But that is a pure technicality, because I will
certainly stop pulling on the 23rd at the latest, and if I get roped
into xmas food prep, even that date might be questionable.

I could extend the merge window rather than cut it short, but I'm not
going to. I suspect we all want a nice calm winter break, so if your
stuff isn't ready to be merged early, the solution is to just not
merge it yet at all, and wait for 4.11. Just so you all know (I
already bcc'd the main merge window suspects in a separate mailing
last week, I'm just repeating myself here to avoid anybody being
confused about timing).

Anyway, back to 4.9 itself.

I'm pretty sure this is the biggest release we've ever had, at least
in number of commits. If you look at the number of lines changed,
we've had bigger releases in the past, but they have tended to be due
to specific issues (v4.2 got a lot of lines from the AMD GPU register
definition files, for example, and we've had big re-organizations that
caused a lot of lines in the past: v3.2 was big due to staging, v3.7
had the automated uapi header file disintegration, etc). In contrast,
4.9 is just big.

Admittedly a chunk of that is the new greybus staging support, but
that really isn't the bulk of it - it's just another small detail in
the overall "yes, v4.9 is big" picture.

Other than just the size, 4.9 looks fairly normal. A bit over two
thirds drivers (staging, GPU and networking are the bulk of it, but
it's all over), with the rest looking fairly normal too: arch updates,
documentation, generic networking, filesystems..

The shortlog (16k+ commits, with another 1100 merge commits to round
things out) is obviously much too big to put here, and wouldn't be
legible anyway. So as is my wont, I'm appending just the log of my
merges.

   Linus

---

Al Viro (10):
VFS splice updates
misc vfs updates
splice fixups
vfs xattr updates
more vfs updates
uaccess.h prepwork
more misc uaccess and vfs updates
VFS fixes
vfs fixes
vfs splice fix

Alex Williamson (2):
VFIO updates
VFIO fix

Alexandre Belloni (2):
RTC updates
RTC fixes

Andrew Morton (7):
updates
more updates
misc fixes x5

Anna Schumaker (4):
NFS client updates
NFS client bugfixes x3

Arnd Bergmann (10):
ARM SoC cleanups
ARM SoC platform updates
ARM SoC defconfig updates
ARM SoC 64-bit updates
ARM SoC driver updates
ARM DT updates
ARM 64-bit DT updates
ARM SoC late DT updates
fixes for -Wmaybe-uninitialized
ARM SoC fixes

Bjorn Andersson (2):
remoteproc updates
rpmsg updates

Bjorn Helgaas (5):
PCI updates
PCI fixes x4

Bob Peterson (1):
gfs2 updates

Borislav Petkov (1):
EDAC updates

Brian Norris (2):
MTD updates
MTD fixes

Bruce Fields (3):
nfsd updates
nfsd bugfixes
nfsd bugfix

Chris Mason (4):
btrfs updates
btrfs fixes x3

Chris Metcalf (2):
arch/tile bugfix
arch/tile bugfix

Corey Minyard (1):
IPMI updates

Dan Williams (4):
libnvdimm updates
libnvdimm fixes x3

Darren Hart (3):
x86 platform drivers updates
x86 platform driver fixes x2

Dave Airlie (10):
drm updates
drm fixes
more drm fixes
drm x86/pat regression fixes
drm fixes x5
drm fix

Dave Chinner (4):
xfs and iomap updates
XFS support for shared data extents
xfs fixes
xfs fix

David Kleikamp (1):
jfs updates

David Miller (16):
networking updates
sparc updates
networking fixups
networking fixes x9
sparc fixes x3
sparc fix

David Teigland (1):
dlm fix

David Vrabel (2):
xen updates
xen fixes

David Woodhouse (1):
IOMMU fixes

Dmitry Torokhov (4):
input subsystem updates
some more input subsystem updates
input subsystem updates
input fixes

Doug Ledford (6):
hdi1 rdma driver updates
main rdma updates
more rdma updates x2
rdma qedr RoCE driver
rmda fixes

Eric Biederman (1):
namespace updates

Geert Uytterhoeven (2):
m68k updates
m68k fixes

Greg KH (14):
char/misc driver updates
driver core updates
tty and serial updates
usb/phy/extcon updates
staging and IIO updates
USB fixes
tty/serial driver fixes
staging and IIO driver fixes
driver core fixes
char/misc driver fixes
USB / PHY fixes
driver core fixes
char/misc fixes
USB fixes

Greg Ungerer (1):
m68knommu updates

Grek KH (1):
staging/IIO fixes

Guenter Roeck (4):
hwmon updates
hwmon fixes
hwmon fix
openrisc fix

Hans-Christian Noren Egtvedt (1):
avr32 update

Helge Deller (5):
parisc updates x2
parisc fixes x3

Re: Note on 4.10 merge window timing (was Re: Linux 4.9-rc8)

[Linus Torvalds]

On Wed, Dec 7, 2016 at 4:04 PM, Al Viro  wrote:
>
> Could you run this just before cutting 4.10-rc1?

Sure. I hope you'll remind me just in case, though.

Especially since xmas eve in the Torvalds household tends to involve
glögg and snaps.

Linus

Re: Note on 4.10 merge window timing (was Re: Linux 4.9-rc8)

[Al Viro]

On Wed, Dec 07, 2016 at 10:32:47AM -0800, Linus Torvalds wrote:

> Btw, for anybody with a calendar (or just excellent finger counting
> skills), this should all be obvious, but I thought I'd make it very
> explicit anyway: this means that 4.9 will be released this upcoming
> Sunday, December 11th. Unless something really bad happens.
> 
> Now, for people counting along, that would mean that the merge window
> for 4.10 ends two weeks later, on December 25.
> 
> That date may look familiar. It's Christmas Day. If you're originally
> from Finland like me, it's the day when you relax after the real
> celebrations, which would be on Christmas Eve.
> 
> What does this all mean? It means that I might be doing the actual rc1
> release on the 25th, but I'm sure as hell not going to do any real
> work that day, or even the day before. So realistically, this is going
> to be a truncated merge window, and if you don't send in your pull
> requests in a timely manner, they are going to be dropped on the
> floor.

Could you run this just before cutting 4.10-rc1?

PATT='^[[:blank:]]*#[[:blank:]]*include[[:blank:]]*'
sed -i -e "s!$PATT!#include !" \
`git grep -l "$PATT"|grep -v ^include/linux/uaccess.h`

Doing that against 4.9 would only cause a bunch of pointless trivial
conflicts during the merge window and would probably need to be run
again to pick the newly added includes of asm/uaccess.h after the end
of the window anyway.  It's 100% mechanical search-and-replace - the only
remaining include of asm/uaccess.h should be in linux/uaccess.h and
everything else should switch to asm/uaccess.h.  There used to be several
places where linux/uaccess.h would cause trouble (the worst was probably
asm/processor.h on x86), but all of those had been taken out and shot during
the last window and AFAICS nothing new of that sort has appeared in anything
merged into -next.

Note on 4.10 merge window timing (was Re: Linux 4.9-rc8)

[Linus Torvalds]

[ people I pulled from during the last merge window added in the bcc.
Except i probably messed up the name->email conversion, so if you
don't get it, it's because I'm incompetent ]

On Sun, Dec 4, 2016 at 1:30 PM, Linus Torvalds
 wrote:
>
> So if anybody has been following the git tree, it should come as no
> surprise that I ended up doing an rc8 after all [..]

Btw, for anybody with a calendar (or just excellent finger counting
skills), this should all be obvious, but I thought I'd make it very
explicit anyway: this means that 4.9 will be released this upcoming
Sunday, December 11th. Unless something really bad happens.

Now, for people counting along, that would mean that the merge window
for 4.10 ends two weeks later, on December 25.

That date may look familiar. It's Christmas Day. If you're originally
from Finland like me, it's the day when you relax after the real
celebrations, which would be on Christmas Eve.

What does this all mean? It means that I might be doing the actual rc1
release on the 25th, but I'm sure as hell not going to do any real
work that day, or even the day before. So realistically, this is going
to be a truncated merge window, and if you don't send in your pull
requests in a timely manner, they are going to be dropped on the
floor.

So I would _strongly_ suggest people try to send their pull requests
during the first week of the merge window. Not only is 4.10 shaping up
to be on the smaller side (presumably because 4.9 is so big), but
thanks to rc8 you all had an extra week to prepare. In fact, you can
start sending me pull requests already, I just won't be actually
pulling until next week.

Yes, yes, I could have instead extended the merge window (I've done so
in the past), but considering the above, I'd much rather we all take a
break over the holidays and get the merge window over and done with
early.

Just so you know. I'm not going to be at all interested in late pull
requests. At that point, things will be ruthlessly just skipped and
they can wait for 4.11 instead.

   Linus

Re: Linux 4.9-rc8

[Andrew Donnellan]

On 06/12/16 10:40, Robert LeBlanc wrote:

I'm not seeing a tag at
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/
. Was it pushed?


You should probably be looking at 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/, where 
the tag certainly was pushed.



Andrew
--
Andrew Donnellan  OzLabs, ADL Canberra
andrew.donnel...@au1.ibm.com  IBM Australia Limited

Re: Linux 4.9-rc8

[Robert LeBlanc]

_sk_policy_lookup
>   netfilter: fix nf_conntrack_helper documentation
>   netfilter: nat: fix cmp return value
>   netfilter: nat: switch to new rhlist interface
>   netfilter: nat: fix crash when conntrack entry is re-used
>   netfilter: ipv6: nf_defrag: drop mangled skb on ream error
>
> Gao Feng (2):
>   driver: ipvlan: Fix one possible memleak in ipvlan_link_new
>   driver: macvtap: Unregister netdev rx_handler if macvtap_newlink fails
>
> Grygorii Strashko (1):
>   net: ethernet: ti: cpsw: fix ASSERT_RTNL() warning during resume
>
> Guillaume Nault (5):
>   l2tp: lock socket before checking flags in connect()
>   l2tp: hold socket before dropping lock in l2tp_ip{, 6}_recv()
>   l2tp: fix racy socket lookup in l2tp_ip and l2tp_ip6 bind()
>   l2tp: fix lookup for sockets not bound to a device in l2tp_ip
>   l2tp: fix address test in __l2tp_ip6_bind_lookup()
>
> Haishuang Yan (1):
>   vxlan: fix a potential issue when create a new vxlan fdb entry.
>
> Hannes Reinecke (2):
>   libata-scsi: Fixup ata_gen_passthru_sense()
>   scsi: hpsa: use bus '3' for legacy HBA devices
>
> Hariprasad Shenai (1):
>   cxgb4: Add PCI device ID for new adapter
>
> Herbert Xu (1):
>   netlink: Call cb->done from a worker thread
>
> Hongxu Jia (1):
>   netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT
> ACCEPT" failed in 64bit kernel
>
> Icenowy Zheng (1):
>   clk: sunxi-ng: enable so-said LDOs for A33 SoC's pll-mipi clock
>
> Jack Morgenstein (1):
>   net/mlx4: Fix uninitialized fields in rule when adding
> promiscuous mode to device managed flow steering
>
> Jan Glauber (1):
>   Revert "i2c: octeon: thunderx: Limit register access retries"
>
> Jason Wang (2):
>   tun: handle ubuf refcount correctly when meet errors
>   macvtap: handle ubuf refcount correctly when meet errors
>
> Jeremy Linton (1):
>   arm64: dts: juno: Correct PCI IO window
>
> Jiri Pirko (1):
>   sched: cls_flower: remove from hashtable only in case skip sw
> flag is not set
>
> Joao Pinto (2):
>   PCI: designware: Change maintainer to Joao Pinto
>   PCI: designware-plat: Update author email
>
> Johan Hovold (29):
>   net: dsa: fix fixed-link-phy device leaks
>   net: bcmgenet: fix phydev reference leak
>   net: fsl/fman: fix phydev reference leak
>   net: fsl/fman: fix fixed-link-phydev reference leak
>   net: qcom/emac: fix of_node and phydev leaks
>   pwm: Fix device reference leak
>   net: dsa: slave: fix of-node leak and phy priority
>   of_mdio: add helper to deregister fixed-link PHYs
>   net: ethernet: altera: fix fixed-link phydev leaks
>   net: ethernet: aurora: nb8800: fix fixed-link phydev leaks
>   net: ethernet: bcmsysport: fix fixed-link phydev leaks
>   net: ethernet: bcmgenet: fix fixed-link phydev leaks
>   net: ethernet: fec: fix fixed-link phydev leaks
>   net: ethernet: fs_enet: fix fixed-link phydev leaks
>   net: ethernet: gianfar: fix fixed-link phydev leaks
>   net: ethernet: ucc_geth: fix fixed-link phydev leaks
>   net: ethernet: marvell: mvneta: fix fixed-link phydev leaks
>   net: ethernet: mediatek: fix fixed-link phydev leaks
>   net: ethernet: renesas: ravb: fix fixed-link phydev leaks
>   net: ethernet: dwc_eth_qos: fix fixed-link phydev leaks
>   net: ethernet: ti: davinci_emac: fix fixed-link phydev and of-node leaks
>   net: dsa: slave: fix fixed-link phydev leaks
>   net: ethernet: stmmac: dwmac-socfpga: fix use-after-free on probe errors
>   net: ethernet: stmmac: dwmac-sti: fix probe error path
>   net: ethernet: stmmac: dwmac-rk: fix probe error path
>   net: ethernet: stmmac: dwmac-generic: fix probe error path
>   net: ethernet: stmmac: dwmac-meson8b: fix probe error path
>   net: ethernet: stmmac: platform: fix outdated function header
>   net: ethernet: stmmac: fix of-node and fixed-link-phydev leaks
>
> Johannes Thumshirn (3):
>   scsi: libfc: fix seconds_since_last_reset miscalculation
>   PCI: Export pcie_find_root_port
>   PCI: Set Read Completion Boundary to 128 iff Root Port supports it 
> (_HPX)
>
> Jon Paul Maloy (1):
>   tipc: fix link statistics counter errors
>
> Josef Bacik (1):
>   bpf: fix states equal logic for varlen access
>
> Julian Wollrath (1):
>   tcp: Set DEFAULT_TCP_CONG to bbr if DEFAULT_BBR is set
>
> Jérémy Lefaure (1):
>   mm, thp: propagation of conditional compilation in khugepaged.c
>
> Kirill A. Shutemov (2):
>   thp: fix corner case of munlock() of

Re: Linux 4.9: Reported regressions as of Sunday, 2016-12-04

[Adam Borowski]

On Sun, Dec 04, 2016 at 01:26:05PM +0100, Thorsten Leemhuis wrote:
> Desc: builddeb: fix cross-building to arm64 producing host-arch debs
> Repo: 16-11-04 https://www.spinics.net/lists/linux-kbuild/msg13635.html
> Stat: 16-11-11 https://www.spinics.net/lists/linux-kbuild/msg13696.html
> Note: Nothing happened when Adam pinged Michael in 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1276268.html

The fix has been accepted and is sitting in kbuild/rc-fixes; I guess Michal
wanted to wait for something else to pop up to not bother Linus with
excessive one-patch pulls.  And we had the modversions brouchacha that was a
far more important regression in the kbuild land.

This cross-building fail is not that vital: arm64 has nothing in between:
* small SoCs with custom (and thus unpackaged) u-boot setups, it's less work
  to configure to boot Image rather than vmlinuz-$KVER, and they're so
  fragile their u-boot breaks if you as much as look at it funny
* fat 48-way servers that you're likely to cross-build on rather than for

I'm insisting on fixing this in 4.9 rather than 4.10 only because it's LTS
both for kernel and for Debian, thus people are going to use *deb-pkg.

So as long as the queue is flushed within this week, all is fine.


Meow!
-- 
u-boot problems can be solved with the help of your old SCSI manuals, the
parts that deal with goat termination.  You need a black-handled knife, and
an appropriate set of candles (number and color matters).  Or was it a
silver-handled knife?  Crap, need to look that up.

Linux 4.9-rc8

[Linus Torvalds]

tp_ip6_bind_lookup()

Haishuang Yan (1):
  vxlan: fix a potential issue when create a new vxlan fdb entry.

Hannes Reinecke (2):
  libata-scsi: Fixup ata_gen_passthru_sense()
  scsi: hpsa: use bus '3' for legacy HBA devices

Hariprasad Shenai (1):
  cxgb4: Add PCI device ID for new adapter

Herbert Xu (1):
  netlink: Call cb->done from a worker thread

Hongxu Jia (1):
  netfilter: arp_tables: fix invoking 32bit "iptable -P INPUT
ACCEPT" failed in 64bit kernel

Icenowy Zheng (1):
  clk: sunxi-ng: enable so-said LDOs for A33 SoC's pll-mipi clock

Jack Morgenstein (1):
  net/mlx4: Fix uninitialized fields in rule when adding
promiscuous mode to device managed flow steering

Jan Glauber (1):
  Revert "i2c: octeon: thunderx: Limit register access retries"

Jason Wang (2):
  tun: handle ubuf refcount correctly when meet errors
  macvtap: handle ubuf refcount correctly when meet errors

Jeremy Linton (1):
  arm64: dts: juno: Correct PCI IO window

Jiri Pirko (1):
  sched: cls_flower: remove from hashtable only in case skip sw
flag is not set

Joao Pinto (2):
  PCI: designware: Change maintainer to Joao Pinto
  PCI: designware-plat: Update author email

Johan Hovold (29):
  net: dsa: fix fixed-link-phy device leaks
  net: bcmgenet: fix phydev reference leak
  net: fsl/fman: fix phydev reference leak
  net: fsl/fman: fix fixed-link-phydev reference leak
  net: qcom/emac: fix of_node and phydev leaks
  pwm: Fix device reference leak
  net: dsa: slave: fix of-node leak and phy priority
  of_mdio: add helper to deregister fixed-link PHYs
  net: ethernet: altera: fix fixed-link phydev leaks
  net: ethernet: aurora: nb8800: fix fixed-link phydev leaks
  net: ethernet: bcmsysport: fix fixed-link phydev leaks
  net: ethernet: bcmgenet: fix fixed-link phydev leaks
  net: ethernet: fec: fix fixed-link phydev leaks
  net: ethernet: fs_enet: fix fixed-link phydev leaks
  net: ethernet: gianfar: fix fixed-link phydev leaks
  net: ethernet: ucc_geth: fix fixed-link phydev leaks
  net: ethernet: marvell: mvneta: fix fixed-link phydev leaks
  net: ethernet: mediatek: fix fixed-link phydev leaks
  net: ethernet: renesas: ravb: fix fixed-link phydev leaks
  net: ethernet: dwc_eth_qos: fix fixed-link phydev leaks
  net: ethernet: ti: davinci_emac: fix fixed-link phydev and of-node leaks
  net: dsa: slave: fix fixed-link phydev leaks
  net: ethernet: stmmac: dwmac-socfpga: fix use-after-free on probe errors
  net: ethernet: stmmac: dwmac-sti: fix probe error path
  net: ethernet: stmmac: dwmac-rk: fix probe error path
  net: ethernet: stmmac: dwmac-generic: fix probe error path
  net: ethernet: stmmac: dwmac-meson8b: fix probe error path
  net: ethernet: stmmac: platform: fix outdated function header
  net: ethernet: stmmac: fix of-node and fixed-link-phydev leaks

Johannes Thumshirn (3):
  scsi: libfc: fix seconds_since_last_reset miscalculation
  PCI: Export pcie_find_root_port
  PCI: Set Read Completion Boundary to 128 iff Root Port supports it (_HPX)

Jon Paul Maloy (1):
  tipc: fix link statistics counter errors

Josef Bacik (1):
  bpf: fix states equal logic for varlen access

Julian Wollrath (1):
  tcp: Set DEFAULT_TCP_CONG to bbr if DEFAULT_BBR is set

Jérémy Lefaure (1):
  mm, thp: propagation of conditional compilation in khugepaged.c

Kirill A. Shutemov (2):
  thp: fix corner case of munlock() of PTE-mapped THPs
  mm: fix false-positive WARN_ON() in truncate/invalidate for hugetlb

Kristian Evensen (1):
  cdc_ether: Fix handling connection notification

Laura Garcia Liebana (1):
  netfilter: nft_hash: validate maximum value of u32 netlink hash attribute

Lino Sanfilippo (2):
  net: ethernet: altera: TSE: Remove unneeded dma sync for tx buffers
  net: ethernet: altera: TSE: do not use tx queue lock in tx
completion handler

Linus Torvalds (3):
      Re-enable CONFIG_MODVERSIONS in a slightly weaker form
  Fix up a couple of field names in the CREDITS file
  Linux 4.9-rc8

Liping Zhang (1):
  netfilter: nft_range: add the missing NULL pointer check

Loic Pallardy (1):
  ARM: dts: STiH407-family: fix i2c nodes

Marc Zyngier (1):
  KVM: arm/arm64: vgic: Don't notify EOI for non-SPIs

Martin Blumenstingl (2):
  Documentation: devicetree: clarify usage of the RGMII phy-modes
  net: phy: realtek: fix enabling of the TX-delay for RTL8211F

Matthew Auld (1):
  drm/i915: drop the struct_mutex when wedged or trying to reset

Maxime Ripard (1):
  ARM: gr8: Rename the DTSI and relevant DTS

Michael Holzheu (1):
  bpf/samples: Fix PT_REGS_IP on s390x and use it

Michal Hocko (2):
  mm: workingset: fix NULL ptr in count_shadow_nodes
  mm, vmscan: add cond_resched() into shrink_node_memcg()

Michal Kubeček (1):
  tipc: check 

Re: Linux 4.9-rc6

[Eric Dumazet]

On Sun, 2016-12-04 at 03:10 -0800, Linus Torvalds wrote:
> 
> 
> On Dec 4, 2016 02:43, "Thorsten Leemhuis" 
> wrote:
> 
> 
> What the status of below patch? From the discussion it looks a
> lot like
> it was developed to fix a regression in 4.9, but the patch
> afaics has
> neither his mainline or linux-next yet. 
> 
> 
> It's not a regression as far as I can tell. It's a small optimization.
> Maybe.
> 
> 
> It's not going into 4.9, is not even clear it's worth it later either,
> unless somebody had numbers (which I haven't seen)
> 
Right, the patch was not in anyway ready for 4.9 ;)

I'll try to complete this for next cycle.

Thanks.

Linux 4.9: Reported regressions as of Sunday, 2016-12-04

[Thorsten Leemhuis]

Hi! Here is my fifth regression report for Linux 4.9. It lists 11
regressions I'm aware of. 4 of them are new; 6 got fixed since 
the last report -- that was two weeks ago, because I yet again
didn't find any spare time to compile a report last Sunday :-/

As always: Are you aware of any other regressions? Then please let me
know (simply CC regressi...@leemhuis.info). And please tell me if there
is anything in the report that shouldn't be there.

Ciao, Thorsten

== Current regressions ==

Desc: System hang up with call trace during doing S3/S4 stress
Repo: 16-12-01 https://bugzilla.kernel.org/show_bug.cgi?id=189421
Stat: n/a 
Note: Brand new

Desc: x86/unwind: Fix guess-unwinder regression // With frame pointers 
disabled, /proc//stack is broken
Repo: 16-11-28 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1281244.html
Stat: n/a 
Note: Fix heading upstream

Desc: [lkp] [mremap] 5d1904204c: will-it-scale.per_thread_ops -13.1% regression
Repo: 16-11-27 https://www.spinics.net/lists/linux-mm/msg117307.html
Stat: n/a 
Note: Aaron could not reproduce the issue on two of his machines

Desc: sched: fix find_idlest_group for fork/performance regression in hackbench
Repo: 16-11-25 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1280514.html
Stat: 16-12-04 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1285936.html
Note: Report contains patch to fix this, testing ongoing

Desc: GPU hang on resume from hibernation
Repo: 16-10-16 https://bugs.freedesktop.org/show_bug.cgi?id=98288#c9 
https://bugzilla.kernel.org/show_bug.cgi?id=177701
Stat: n/a 
Note: confusing bug, but seems the issue is still present

Desc: GPU hang on PlaneShift
Repo: 16-10-16 https://bugs.freedesktop.org/show_bug.cgi?id=98922 
https://bugzilla.kernel.org/show_bug.cgi?id=177701
Stat: n/a 
Note: confusing bug, but the issue might still be present

Desc: [i.MX6 DRM IPUv3] Regression 4.9-rc5: greenish screen with YUV420 video
Repo: 16-11-17 https://www.spinics.net/lists/kernel/msg2385550.html
Stat: 16-12-02 https://www.spinics.net/lists/kernel/msg2396720.html
Note: "patch available: 3fd8b292ae6b (""drm/imx: ipuv3-plane: merge 
ipu_plane_atomic_set_base into atomic_update"")"

Desc: "Failed boots/Package drops bisected to 4cd13c21b207 ""softirq: Let 
ksoftirqd do its job""; "
Repo: 16-11-16 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1273344.html
Stat: 16-11-25 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1280379.html
Note: Stalled

Desc: builddeb: fix cross-building to arm64 producing host-arch debs
Repo: 16-11-04 https://www.spinics.net/lists/linux-kbuild/msg13635.html
Stat: 16-11-11 https://www.spinics.net/lists/linux-kbuild/msg13696.html
Note: Nothing happened when Adam pinged Michael in 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1276268.html


== Stalled, waiting for feedback from reporter ==

Desc: 4.9-rc1 boot regression, ambiguous bisect result
Repo: 2016-10-19 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253369.html
Stat: 16-10-21 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1255296.html
Note: Waiting for Dan or someone else to look into this

Desc: Skylake gen6 suspend/resume video regression
Repo: 16-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177731 
https://bugs.freedesktop.org/show_bug.cgi?id=98517
Stat: 16-10-31 https://bugzilla.kernel.org/show_bug.cgi?id=177731#c7
Note: Stalled

== Fixed since last report ==

Desc: module loadling broken due to kbuild changes
Repo: 16-10-15 http://www.gossamer-threads.com/lists/linux/kernel/2544734 and 
various other threads (https://lwn.net/Articles/707520/ )
Fix:  
https://git.kernel.org/torvalds/c/cd3caefb4663e3811d37cc2afad3cce642d60061 
https://git.kernel.org/torvalds/c/faaae2a581435f32781a105dda3501df388fddcb 
(among others)

Desc: "irq 16: nobody cared (try booting with the ""irqpoll"" option) since 
t0b9e2988ab226 (ahci: use pci_alloc_irq_vectors)"
Repo: 16-11-19 https://bugzilla.kernel.org/show_bug.cgi?id=188181
Stat: 16-12-03 https://bugzilla.kernel.org/show_bug.cgi?id=188181#c9
Note: Fixed according to reporter (might be thx to 
https://git.kernel.org/torvalds/c/6929ef385e09c0065b87fda3e7b872a5070ac783 )

Desc: "build regression: make.cross ARCH=mips fails with ""No rule to make 
target 'alchemy/devboards/'. """
Repo: 16-10-30 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262410.html 
https://marc.info/?l=linux-kernel&m=147780880425626
Fix:  https://git.kernel.org/torvalds/c/818f38c5b7c4482abd71c64ac4d49911fbefaf9e

Desc: "oops due to 493b2ed3f760 (""crypto: algif_hash - Handle NULL hashes 
correctly"")"
Repo: 16-11-17 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1273867.html
Fix:  https://git.kernel.org/torvalds/c/a8348bca2944d397a528772f5c0ccb47

Re: Linux 4.9-rc6

[Thorsten Leemhuis]

Lo! On 21.11.2016 14:51, Eric Dumazet wrote:
> On Mon, 2016-11-21 at 05:32 -0800, Eric Dumazet wrote:
>> Oh, this was definitely my intent of course, thanks for noticing this
>> typo ;)
> V2 is fixing this, and brings back NUMA spreading,
> (eg alloc_large_system_hash() done at boot time )

What the status of below patch? From the discussion it looks a lot like
it was developed to fix a regression in 4.9, but the patch afaics has
neither his mainline or linux-next yet. That's why I'm inclined to add
it to this weeks regression report.

Ciao, Thorsten

> lpaa24:~# grep alloc_large /proc/vmallocinfo 
> 0xc9009000-0xc900c000   12288 
> alloc_large_system_hash+0x178/0x238 pages=2 vmalloc N0=1 N1=1
> 0xc900c000-0xc900f000   12288 
> alloc_large_system_hash+0x178/0x238 pages=2 vmalloc N0=1 N1=1
> 0xc901e000-0xc909f000  528384 
> alloc_large_system_hash+0x178/0x238 pages=128 vmalloc N0=64 N1=64
> 0xc909f000-0xc90e  266240 
> alloc_large_system_hash+0x178/0x238 pages=64 vmalloc N0=32 N1=32
> 0xc91d3000-0xc900101d4000 268439552 
> alloc_large_system_hash+0x178/0x238 pages=65536 vmalloc vpages N0=32768 
> N1=32768
> 0xc900101d4000-0xc900181d5000 134221824 
> alloc_large_system_hash+0x178/0x238 pages=32768 vmalloc vpages N0=16384 
> N1=16384
> 0xc900181d5000-0xc900185d6000 4198400 
> alloc_large_system_hash+0x178/0x238 pages=1024 vmalloc vpages N0=512 N1=512
> 0xc900185d6000-0xc900189d7000 4198400 
> alloc_large_system_hash+0x178/0x238 pages=1024 vmalloc vpages N0=512 N1=512
> 0xc9001b271000-0xc9001b672000 4198400 
> alloc_large_system_hash+0x178/0x238 pages=1024 vmalloc vpages N0=512 N1=512
> 0xc9001b672000-0xc9001b675000   12288 
> alloc_large_system_hash+0x178/0x238 pages=2 vmalloc N0=1 N1=1
> 0xc9001b675000-0xc9001b776000 1052672 
> alloc_large_system_hash+0x178/0x238 pages=256 vmalloc N0=128 N1=128
> 0xc9001b776000-0xc9001b977000 2101248 
> alloc_large_system_hash+0x178/0x238 pages=512 vmalloc N0=256 N1=256
> 0xc9001b977000-0xc9001bb78000 2101248 
> alloc_large_system_hash+0x178/0x238 pages=512 vmalloc N0=256 N1=256
> 0xc9001c075000-0xc9001c176000 1052672 
> alloc_large_system_hash+0x178/0x238 pages=256 vmalloc N0=128 N1=128
> 
> 
>  mm/vmalloc.c |   47 +++
>  1 file changed, 39 insertions(+), 8 deletions(-)
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index f2481cb4e6b2..f4b9c9238f86 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1602,9 +1603,11 @@ static void *__vmalloc_area_node(struct vm_struct 
> *area, gfp_t gfp_mask,
>pgprot_t prot, int node)
>  {
>   struct page **pages;
> - unsigned int nr_pages, array_size, i;
> + unsigned int nr_pages, array_size, i, j;
>   const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
>   const gfp_t alloc_mask = gfp_mask | __GFP_NOWARN;
> + const gfp_t multi_alloc_mask = (alloc_mask & ~__GFP_DIRECT_RECLAIM) | 
> __GFP_NORETRY;
> + int max_node_order = MAX_ORDER - 1;
>  
>   nr_pages = get_vm_area_size(area) >> PAGE_SHIFT;
>   array_size = (nr_pages * sizeof(struct page *));
> @@ -1624,20 +1627,48 @@ static void *__vmalloc_area_node(struct vm_struct 
> *area, gfp_t gfp_mask,
>   return NULL;
>   }
>  
> - for (i = 0; i < area->nr_pages; i++) {
> - struct page *page;
> + if (IS_ENABLED(CONFIG_NUMA) && nr_online_nodes > 1) {
> + struct mempolicy *policy = current->mempolicy;
> + int pages_per_node;
>  
> - if (node == NUMA_NO_NODE)
> - page = alloc_page(alloc_mask);
> - else
> - page = alloc_pages_node(node, alloc_mask, 0);
> + if (policy && policy->mode == MPOL_INTERLEAVE) {
> + pages_per_node = DIV_ROUND_UP(nr_pages,
> +   nr_online_nodes);
> + max_node_order = min(max_node_order,
> +  ilog2(pages_per_node));
> + }
> + }
> +
> + for (i = 0; i < area->nr_pages;) {
> + unsigned int chunk_order = min(ilog2(area->nr_pages - i),
> +max_node_order);
> + struct page *page = NULL;
> +
> + while (chunk_order) {
> + if (node == NUMA_NO_NODE)
> + page = alloc_pages(multi_alloc_mask, 
> chunk_order);
> + else
> + page = alloc_pages_node(node, multi_alloc_mask, 
> chunk_order);
> + if (page) {
> + split_page(page, chunk_order);
> + break;
> + }
> +  

Linux 4.9-rc7

[Linus Torvalds]

 mac80211: remove bogus skb vif assignment
  mac80211: fix A-MSDU aggregation with fast-xmit + txq

Felix Hädicke (1):
  usb: gadget: f_fs: fix wrong parenthesis in ffs_func_req_match()

Filip Matusiak (1):
  mac80211: Ignore VHT IE from peer with wrong rx_mcs_map

Florian Fainelli (2):
  net: dsa: b53: Fix VLAN usage and how we treat CPU port
  net: dsa: bcm_sf2: Ensure we re-negotiate EEE during after link change

Florian Westphal (1):
  tcp: zero ca_priv area when switching cc algorithms

Gao Feng (2):
  net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit
  driver: macvlan: Check if need rollback multicast setting in macvlan_open

Geliang Tang (5):
  sparc: drop duplicate header scatterlist.h
  dwc_eth_qos: drop duplicate headers
  ibmvnic: drop duplicate header seq_file.h
  net: ieee802154: drop duplicate header delay.h
  net/mlx5: drop duplicate header delay.h

Giuseppe CAVALLARO (3):
  stmmac: update the PTP header file
  stmmac: fix PTP support for GMAC4
  stmmac: fix PTP type ethtool stats

Guillaume Nault (1):
  l2tp: fix racy SOCK_ZAPPED flag check in l2tp_ip{,6}_bind()

H.J. Lu (1):
  x86/build: Build compressed x86 kernels as PIE when
!CONFIG_RELOCATABLE as well

Hangbin Liu (1):
  igmp: do not remove igmp souce list info when set link down

Helge Deller (2):
  parisc: Fix printk continuations in system detection
  parisc: Switch to generic sched_clock implementation

Herbert Xu (2):
  crypto: algif_hash - Fix result clobbering in recvmsg
  crypto: scatterwalk - Remove unnecessary aliasing check in map_and_copy

Jacob Pan (1):
  thermal/powerclamp: add back module device table

Jaehoon Chung (1):
  mmc: dw_mmc: fix the error handling for dma operation

Janakarajan Natarajan (1):
  perf/x86: Add perf support for AMD family-17h processors

Jarkko Nikula (1):
  Revert "i2c: designware: do not disable adapter after transfer"

Jeremy Linton (1):
  net: sky2: Fix shutdown crash

Jia Jie Ho (1):
  net: ethernet: Fix SGMII unable to switch speed and autonego failure

Jitao Shi (1):
  drm/mediatek: fixed the calc method of data rate per lane

Johan Hedberg (1):
  Bluetooth: Fix using the correct source address type

Johan Hovold (10):
  of_mdio: fix node leak in of_phy_register_fixed_link error path
  of_mdio: fix device reference leak in of_phy_find_device
  net: phy: fixed_phy: fix of_node leak in fixed_phy_unregister
  net: ethernet: ti: cpsw: fix bad register access in probe error path
  net: ethernet: ti: cpsw: fix mdio device reference leak
  net: ethernet: ti: cpsw: fix deferred probe
  net: ethernet: ti: cpsw: fix of_node and phydev leaks
  net: ethernet: ti: cpsw: fix secondary-emac probe error path
  net: ethernet: ti: cpsw: add missing sanity check
  net: ethernet: ti: cpsw: fix fixed-link phy probe deferral

Johannes Berg (1):
  cfg80211: limit scan results cache size

Johannes Weiner (1):
  perf/x86: Restore TASK_SIZE check on frame pointer

John David Anglin (3):
  parisc: Fix races in parisc_setup_cache_timing()
  parisc: Fix race in pci-dma.c
  parisc: Also flush data TLB in flush_icache_page_asm

John Johansen (1):
  apparmor: fix change_hat not finding hat after policy replacement

Jon Paul Maloy (4):
  tipc: eliminate obsolete socket locking policy description
  tipc: fix compatibility bug in link monitoring
  tipc: improve sanity check for received domain records
  tipc: resolve connection flow control compatibility problem

Josef Bacik (1):
  bpf: fix range arithmetic for bpf map access

Josh Poimboeuf (2):
  x86/unwind: Prevent KASAN false positive warnings in guess unwinder
  x86/dumpstack: Prevent KASAN false positive warnings

Kan Liang (1):
  perf/x86/uncore: Fix crash by removing bogus event_list[]
handling for SNB client uncore IMC

Kirill Esipov (1):
  net: phy: micrel: fix KSZ8041FTL supported value

Linus Torvalds (2):
  Fix subtle CONFIG_MODVERSIONS problems
  Linux 4.9-rc7

Matt Redfearn (1):
  MIPS: mm: Fix output of __do_page_fault

Matthias Brugger (1):
  drm/mediatek: fix null pointer dereference

Mauricio Faria de Oliveira (1):
  scsi: qla2xxx: do not abort all commands in the adapter during
EEH recovery

Michael Walle (1):
  mmc: sdhci-of-esdhc: fixup PRESENT_STATE read

Mika Westerberg (1):
  watchdog: wdat_wdt: Select WATCHDOG_CORE

Miroslav Lichvar (1):
  net: ethtool: don't require CAP_NET_ADMIN for ETHTOOL_GLINKSETTINGS

Nicholas Piggin (1):
  powerpc: Fix missing CRCs, add more asm-prototypes.h declarations

Nicolas Schichan (1):
  init: use pr_cont() when displaying rotator during ramdisk loading.

Oleg Nesterov (2):
  sched/autogroup: Fix autogroup_move_group() to never skip
sched_move_task()
  sched/autogroup: Do not use autogroup->tg in zombie threads

Oliver

Re: Linux 4.9: Reported regressions as of Sunday, 2016-11-20

[Arnd Bergmann]

On Sunday, November 20, 2016 4:09:51 PM CET Thorsten Leemhuis wrote:
> 
> == Fixed since last report ==
> 
> Desc: module loadling broken due to kbuild changes
> Repo: 16-10-15 http://www.gossamer-threads.com/lists/linux/kernel/2544734
> Stat: Fixes 
> https://git.kernel.org/torvalds/c/4efca4ed05cbdfd13ec3e8cb623fb77d6e4ab187 
> https://git.kernel.org/torvalds/c/4efca4ed05cbdfd13ec3e8cb623fb77d6e4ab187
> Note: 

This is currently only fixed for powerpc. Fixes for x86 and ARM were
proposed but not merged, and all other architectures don't even have
a fix as far as I can tell.

It's only broken with CONFIG_MODVERSIONS=y though, and not all modules
are affected on all architectures, so a lot of testers have not noticed.

Arnd

Re: Linux 4.9: Reported regressions as of Sunday, 2016-11-20

[Paul Bolle]

On Sun, 2016-11-20 at 16:09 +0100, Thorsten Leemhuis wrote:
> Desc: "build regression: make.cross ARCH=mips fails with ""No rule to make 
> target 'alchemy/devboards/'. """
> Repo: 16-10-30 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262410.html 
> https://marc.info/?l=linux-kernel&m=147780880425626
> Stat: n/a 
> Note: nothing happened yet; BTW: Should build regressions be on this list at 
> all?

Fixed by commit 818f38c5b7c4 ("MIPS: Fix build of compressed image"). So this
is actually fixed since v4.9-rc4, but I only looked into this again today.

Thanks,


Paul Bolle

Re: Linux 4.9-rc6

[Eric Dumazet]

On Mon, 2016-11-21 at 05:51 -0800, Eric Dumazet wrote:

> + while (chunk_order) {
> + if (node == NUMA_NO_NODE)
> + page = alloc_pages(multi_alloc_mask, 
> chunk_order);
> + else
> + page = alloc_pages_node(node, multi_alloc_mask, 
> chunk_order);
> + if (page) {
> + split_page(page, chunk_order);
> + break;
> + }
> + chunk_order--;
> + }


We also could remember the page order with set_page_private() and
speedup show_numa_info()

I wonder if we could avoid the split_page() and speedup vfree().

Re: Linux 4.9-rc6

[Eric Dumazet]

On Mon, 2016-11-21 at 05:32 -0800, Eric Dumazet wrote:

> 
> Oh, this was definitely my intent of course, thanks for noticing this
> typo ;)

V2 is fixing this, and brings back NUMA spreading,
(eg alloc_large_system_hash() done at boot time )


lpaa24:~# grep alloc_large /proc/vmallocinfo 
0xc9009000-0xc900c000   12288 
alloc_large_system_hash+0x178/0x238 pages=2 vmalloc N0=1 N1=1
0xc900c000-0xc900f000   12288 
alloc_large_system_hash+0x178/0x238 pages=2 vmalloc N0=1 N1=1
0xc901e000-0xc909f000  528384 
alloc_large_system_hash+0x178/0x238 pages=128 vmalloc N0=64 N1=64
0xc909f000-0xc90e  266240 
alloc_large_system_hash+0x178/0x238 pages=64 vmalloc N0=32 N1=32
0xc91d3000-0xc900101d4000 268439552 
alloc_large_system_hash+0x178/0x238 pages=65536 vmalloc vpages N0=32768 N1=32768
0xc900101d4000-0xc900181d5000 134221824 
alloc_large_system_hash+0x178/0x238 pages=32768 vmalloc vpages N0=16384 N1=16384
0xc900181d5000-0xc900185d6000 4198400 
alloc_large_system_hash+0x178/0x238 pages=1024 vmalloc vpages N0=512 N1=512
0xc900185d6000-0xc900189d7000 4198400 
alloc_large_system_hash+0x178/0x238 pages=1024 vmalloc vpages N0=512 N1=512
0xc9001b271000-0xc9001b672000 4198400 
alloc_large_system_hash+0x178/0x238 pages=1024 vmalloc vpages N0=512 N1=512
0xc9001b672000-0xc9001b675000   12288 
alloc_large_system_hash+0x178/0x238 pages=2 vmalloc N0=1 N1=1
0xc9001b675000-0xc9001b776000 1052672 
alloc_large_system_hash+0x178/0x238 pages=256 vmalloc N0=128 N1=128
0xc9001b776000-0xc9001b977000 2101248 
alloc_large_system_hash+0x178/0x238 pages=512 vmalloc N0=256 N1=256
0xc9001b977000-0xc9001bb78000 2101248 
alloc_large_system_hash+0x178/0x238 pages=512 vmalloc N0=256 N1=256
0xc9001c075000-0xc9001c176000 1052672 
alloc_large_system_hash+0x178/0x238 pages=256 vmalloc N0=128 N1=128


 mm/vmalloc.c |   47 +++
 1 file changed, 39 insertions(+), 8 deletions(-)

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index f2481cb4e6b2..f4b9c9238f86 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1602,9 +1603,11 @@ static void *__vmalloc_area_node(struct vm_struct *area, 
gfp_t gfp_mask,
 pgprot_t prot, int node)
 {
struct page **pages;
-   unsigned int nr_pages, array_size, i;
+   unsigned int nr_pages, array_size, i, j;
const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
const gfp_t alloc_mask = gfp_mask | __GFP_NOWARN;
+   const gfp_t multi_alloc_mask = (alloc_mask & ~__GFP_DIRECT_RECLAIM) | 
__GFP_NORETRY;
+   int max_node_order = MAX_ORDER - 1;
 
nr_pages = get_vm_area_size(area) >> PAGE_SHIFT;
array_size = (nr_pages * sizeof(struct page *));
@@ -1624,20 +1627,48 @@ static void *__vmalloc_area_node(struct vm_struct 
*area, gfp_t gfp_mask,
return NULL;
}
 
-   for (i = 0; i < area->nr_pages; i++) {
-   struct page *page;
+   if (IS_ENABLED(CONFIG_NUMA) && nr_online_nodes > 1) {
+   struct mempolicy *policy = current->mempolicy;
+   int pages_per_node;
 
-   if (node == NUMA_NO_NODE)
-   page = alloc_page(alloc_mask);
-   else
-   page = alloc_pages_node(node, alloc_mask, 0);
+   if (policy && policy->mode == MPOL_INTERLEAVE) {
+   pages_per_node = DIV_ROUND_UP(nr_pages,
+ nr_online_nodes);
+   max_node_order = min(max_node_order,
+ilog2(pages_per_node));
+   }
+   }
+
+   for (i = 0; i < area->nr_pages;) {
+   unsigned int chunk_order = min(ilog2(area->nr_pages - i),
+  max_node_order);
+   struct page *page = NULL;
+
+   while (chunk_order) {
+   if (node == NUMA_NO_NODE)
+   page = alloc_pages(multi_alloc_mask, 
chunk_order);
+   else
+   page = alloc_pages_node(node, multi_alloc_mask, 
chunk_order);
+   if (page) {
+   split_page(page, chunk_order);
+   break;
+   }
+   chunk_order--;
+   }
+   if (!page) {
+   if (node == NUMA_NO_NODE)
+   page = alloc_pages(alloc_mask, 0);
+   else
+   page = alloc_pages_node(node, alloc_mask, 0);
+   }
 
if (unlikely(!page)) {
/* Successfully allocated i pages, free them in 

Re: Linux 4.9-rc6

[Eric Dumazet]

On Mon, 2016-11-21 at 00:34 -0800, David Rientjes wrote:
> On Sun, 20 Nov 2016, Eric Dumazet wrote:
> 
> > Another potential issue with CONFIG_VMAP_STACK is that we make no
> > attempt to allocate 4 consecutive pages.
> > 
> > Even if we have plenty of memory, 4 calls to alloc_page() are likely to
> > give us 4 pages in completely different locations.
> > 
> > Here I printed the hugepage number of the 4 pages for some stacks :
> > 
> > 
> > 0xc9001a07c000-0xc9001a081000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfcac Hfeba Hfec0 Hfc9d N0=4
> > 0xc9001a084000-0xc9001a089000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfc79 Hfc79 Hfc79 Hfc83 N0=4
> > 0xc9001a08c000-0xc9001a091000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfc9b Hfe91 Hfebe Hfca2 N0=4
> > 0xc9001a094000-0xc9001a099000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfcaa Hfcaa Hfca6 Hfebc N0=4
> > 0xc9001a09c000-0xc9001a0a1000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfe9b Hfe90 Hff09 Hfefb N0=4
> > 0xc9001a0a4000-0xc9001a0a9000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfe94 Hfe62 Hfea0 Hfe7b N0=4
> > 0xc9001a0ac000-0xc9001a0b1000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfe78 Hff05 Hff05 Hfc74 N0=4
> > 0xc9001a0b4000-0xc9001a0b9000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfc9b Hfc9b Hfe83 Hf782 N0=4
> > 0xc9001a0bc000-0xc9001a0c1000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfe78 Hfe78 Hfc7f Hfc7f N0=4
> > 0xc9001a0c4000-0xc9001a0c9000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfebe Hfebe Hfe82 Hfe85 N0=4
> > 0xc9001a0cc000-0xc9001a0d1000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfc6b Hfe62 Hfe62 Hfcaa N0=4
> > 0xc9001a0d4000-0xc9001a0d9000   20480 _do_fork+0xe1/0x360 pages=4 
> > vmalloc Hfebd Hfebd Hfc92 Hfc92 N0=4
> > 
> > This is a vmalloc() generic issue that is worth fixing now ?
> > 
> > Note this RFC might conflict with NUMA interleave policy.
> > 
> > diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> > index f2481cb4e6b2..0123e97debb9 100644
> > --- a/mm/vmalloc.c
> > +++ b/mm/vmalloc.c
> > @@ -1602,9 +1602,10 @@ static void *__vmalloc_area_node(struct vm_struct 
> > *area, gfp_t gfp_mask,
> >  pgprot_t prot, int node)
> >  {
> > struct page **pages;
> > -   unsigned int nr_pages, array_size, i;
> > +   unsigned int nr_pages, array_size, i, j;
> > const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
> > const gfp_t alloc_mask = gfp_mask | __GFP_NOWARN;
> > +   const gfp_t multi_alloc_mask = (gfp_mask & ~__GFP_DIRECT_RECLAIM) | 
> > __GFP_NORETRY;
> >  
> > nr_pages = get_vm_area_size(area) >> PAGE_SHIFT;
> > array_size = (nr_pages * sizeof(struct page *));
> 
> I think multi_alloc_mask wants to use alloc_mask rather than gfp_mask 
> before clearing the bit, otherwise the failed high-order allocations with 
> no chance to reclaim will spew page allocation failure warnings.  Using 
> __GFP_NORETRY here would be a no-op, but it depends on the implementation 
> so no problems setting it.

Oh, this was definitely my intent of course, thanks for noticing this
typo ;)

Re: Linux 4.9-rc6

[David Rientjes]

On Sun, 20 Nov 2016, Eric Dumazet wrote:

> Another potential issue with CONFIG_VMAP_STACK is that we make no
> attempt to allocate 4 consecutive pages.
> 
> Even if we have plenty of memory, 4 calls to alloc_page() are likely to
> give us 4 pages in completely different locations.
> 
> Here I printed the hugepage number of the 4 pages for some stacks :
> 
> 
> 0xc9001a07c000-0xc9001a081000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfcac Hfeba Hfec0 Hfc9d N0=4
> 0xc9001a084000-0xc9001a089000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfc79 Hfc79 Hfc79 Hfc83 N0=4
> 0xc9001a08c000-0xc9001a091000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfc9b Hfe91 Hfebe Hfca2 N0=4
> 0xc9001a094000-0xc9001a099000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfcaa Hfcaa Hfca6 Hfebc N0=4
> 0xc9001a09c000-0xc9001a0a1000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfe9b Hfe90 Hff09 Hfefb N0=4
> 0xc9001a0a4000-0xc9001a0a9000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfe94 Hfe62 Hfea0 Hfe7b N0=4
> 0xc9001a0ac000-0xc9001a0b1000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfe78 Hff05 Hff05 Hfc74 N0=4
> 0xc9001a0b4000-0xc9001a0b9000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfc9b Hfc9b Hfe83 Hf782 N0=4
> 0xc9001a0bc000-0xc9001a0c1000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfe78 Hfe78 Hfc7f Hfc7f N0=4
> 0xc9001a0c4000-0xc9001a0c9000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfebe Hfebe Hfe82 Hfe85 N0=4
> 0xc9001a0cc000-0xc9001a0d1000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfc6b Hfe62 Hfe62 Hfcaa N0=4
> 0xc9001a0d4000-0xc9001a0d9000   20480 _do_fork+0xe1/0x360 pages=4 
> vmalloc Hfebd Hfebd Hfc92 Hfc92 N0=4
> 
> This is a vmalloc() generic issue that is worth fixing now ?
> 
> Note this RFC might conflict with NUMA interleave policy.
> 
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index f2481cb4e6b2..0123e97debb9 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -1602,9 +1602,10 @@ static void *__vmalloc_area_node(struct vm_struct 
> *area, gfp_t gfp_mask,
>pgprot_t prot, int node)
>  {
>   struct page **pages;
> - unsigned int nr_pages, array_size, i;
> + unsigned int nr_pages, array_size, i, j;
>   const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
>   const gfp_t alloc_mask = gfp_mask | __GFP_NOWARN;
> + const gfp_t multi_alloc_mask = (gfp_mask & ~__GFP_DIRECT_RECLAIM) | 
> __GFP_NORETRY;
>  
>   nr_pages = get_vm_area_size(area) >> PAGE_SHIFT;
>   array_size = (nr_pages * sizeof(struct page *));

I think multi_alloc_mask wants to use alloc_mask rather than gfp_mask 
before clearing the bit, otherwise the failed high-order allocations with 
no chance to reclaim will spew page allocation failure warnings.  Using 
__GFP_NORETRY here would be a no-op, but it depends on the implementation 
so no problems setting it.

> @@ -1624,20 +1625,34 @@ static void *__vmalloc_area_node(struct vm_struct 
> *area, gfp_t gfp_mask,
>   return NULL;
>   }
>  
> - for (i = 0; i < area->nr_pages; i++) {
> - struct page *page;
> -
> - if (node == NUMA_NO_NODE)
> - page = alloc_page(alloc_mask);
> - else
> - page = alloc_pages_node(node, alloc_mask, 0);
> + for (i = 0; i < area->nr_pages;) {
> + struct page *page = NULL;
> + unsigned int chunk_order = min(ilog2(area->nr_pages - i), 
> MAX_ORDER - 1);
> +
> + while (chunk_order && !page) {
> + if (node == NUMA_NO_NODE)
> + page = alloc_pages(multi_alloc_mask, 
> chunk_order);
> + else
> + page = alloc_pages_node(node, multi_alloc_mask, 
> chunk_order);
> + if (page)
> + split_page(page, chunk_order);
> + else
> + chunk_order--;
> + }
> + if (!page) {
> + if (node == NUMA_NO_NODE)
> + page = alloc_pages(alloc_mask, 0);
> + else
> + page = alloc_pages_node(node, alloc_mask, 0);
> + }
>  
>   if (unlikely(!page)) {
>   /* Successfully allocated i pages, free them in 
> __vunmap() */
>   area->nr_pages = i;
>   goto fail;
>   }
> - area->pages[i] = page;
> + for (j = 0; j < (1 << chunk_order); j++)
> + area->pages[i++] = page++;
>   if (gfpflags_allow_blocking(gfp_mask))
>   cond_resched();
>   }
> 
> 
> 

Re: Linux 4.9-rc6

[Eric Dumazet]

On Mon, 2016-11-21 at 01:35 +, Al Viro wrote:

> 
> Umm...  One possibility would be something like fs/namespace.c:m_start() -
> if nothing has changed since the last time, just use a cached pointer.
> That has sped the damn thing (/proc/mounts et.al.) big way, but it's
> dependent upon having an event count updated whenever we change the
> mount tree - doing the same for vma_area list might or might not be
> a good idea.  /proc/mounts and friends get ->poll() on that as well;
> that probably would _not_ be a good idea in this case.

Yes, a generation number could help in some cases.

Another potential issue with CONFIG_VMAP_STACK is that we make no
attempt to allocate 4 consecutive pages.

Even if we have plenty of memory, 4 calls to alloc_page() are likely to
give us 4 pages in completely different locations.

Here I printed the hugepage number of the 4 pages for some stacks :


0xc9001a07c000-0xc9001a081000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfcac Hfeba Hfec0 Hfc9d N0=4
0xc9001a084000-0xc9001a089000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfc79 Hfc79 Hfc79 Hfc83 N0=4
0xc9001a08c000-0xc9001a091000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfc9b Hfe91 Hfebe Hfca2 N0=4
0xc9001a094000-0xc9001a099000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfcaa Hfcaa Hfca6 Hfebc N0=4
0xc9001a09c000-0xc9001a0a1000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfe9b Hfe90 Hff09 Hfefb N0=4
0xc9001a0a4000-0xc9001a0a9000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfe94 Hfe62 Hfea0 Hfe7b N0=4
0xc9001a0ac000-0xc9001a0b1000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfe78 Hff05 Hff05 Hfc74 N0=4
0xc9001a0b4000-0xc9001a0b9000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfc9b Hfc9b Hfe83 Hf782 N0=4
0xc9001a0bc000-0xc9001a0c1000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfe78 Hfe78 Hfc7f Hfc7f N0=4
0xc9001a0c4000-0xc9001a0c9000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfebe Hfebe Hfe82 Hfe85 N0=4
0xc9001a0cc000-0xc9001a0d1000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfc6b Hfe62 Hfe62 Hfcaa N0=4
0xc9001a0d4000-0xc9001a0d9000   20480 _do_fork+0xe1/0x360 pages=4 
vmalloc Hfebd Hfebd Hfc92 Hfc92 N0=4

This is a vmalloc() generic issue that is worth fixing now ?

Note this RFC might conflict with NUMA interleave policy.

diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index f2481cb4e6b2..0123e97debb9 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1602,9 +1602,10 @@ static void *__vmalloc_area_node(struct vm_struct *area, 
gfp_t gfp_mask,
 pgprot_t prot, int node)
 {
struct page **pages;
-   unsigned int nr_pages, array_size, i;
+   unsigned int nr_pages, array_size, i, j;
const gfp_t nested_gfp = (gfp_mask & GFP_RECLAIM_MASK) | __GFP_ZERO;
const gfp_t alloc_mask = gfp_mask | __GFP_NOWARN;
+   const gfp_t multi_alloc_mask = (gfp_mask & ~__GFP_DIRECT_RECLAIM) | 
__GFP_NORETRY;
 
nr_pages = get_vm_area_size(area) >> PAGE_SHIFT;
array_size = (nr_pages * sizeof(struct page *));
@@ -1624,20 +1625,34 @@ static void *__vmalloc_area_node(struct vm_struct 
*area, gfp_t gfp_mask,
return NULL;
}
 
-   for (i = 0; i < area->nr_pages; i++) {
-   struct page *page;
-
-   if (node == NUMA_NO_NODE)
-   page = alloc_page(alloc_mask);
-   else
-   page = alloc_pages_node(node, alloc_mask, 0);
+   for (i = 0; i < area->nr_pages;) {
+   struct page *page = NULL;
+   unsigned int chunk_order = min(ilog2(area->nr_pages - i), 
MAX_ORDER - 1);
+
+   while (chunk_order && !page) {
+   if (node == NUMA_NO_NODE)
+   page = alloc_pages(multi_alloc_mask, 
chunk_order);
+   else
+   page = alloc_pages_node(node, multi_alloc_mask, 
chunk_order);
+   if (page)
+   split_page(page, chunk_order);
+   else
+   chunk_order--;
+   }
+   if (!page) {
+   if (node == NUMA_NO_NODE)
+   page = alloc_pages(alloc_mask, 0);
+   else
+   page = alloc_pages_node(node, alloc_mask, 0);
+   }
 
if (unlikely(!page)) {
/* Successfully allocated i pages, free them in 
__vunmap() */
area->nr_pages = i;
goto fail;
}
-   area->pages[i] = page;
+   for (j = 0; j < (1 << chunk_order); j++)
+   area->pages[i++] = page++;
if (gfpflags_allow_blocking(gfp_mask))
cond_resched();
}

Re: Linux 4.9-rc6

[Al Viro]

On Sun, Nov 20, 2016 at 03:27:07PM -0800, Linus Torvalds wrote:
> On Sun, Nov 20, 2016 at 2:27 PM, Eric Dumazet  wrote:
> >
> > Hosts with ~100,000 threads have an issue with /prov/vmallocinfo
> >
> > It can take about 800 usec to skip over ~100,000 struct vmap_area
> > in s_start(), while holding vmap_area_lock spinlock, and therefore
> > blocking fork()/pthread_create().
> >
> > I presume we can not switch to the rbtree (vmap_area_root)
> > for /proc/vmallocinfo, because this file is seek-able, right ?
> 
> Well, the good news is that the file is root-only anyway, which means
> that at least it won't have the issue that a lot of other /proc files
> have had - namely being opened by random user programs or libraries.
> 
> Which means that the users of it are likely fairly limited.
> 
> Which in turn means that we can probably afford to play more games
> with it. Including, for example, possibly marking it non-seekable.
> 
> Or even just limit the maximum entries we are willing to walk.
> 
> Or we could decide that that file shouldn't be a seq_file at all, use
> the old "one page buffer" approach that was so common for /proc files,
> and make the position encode the vmalloc address in it (make the lower
> PAGE_MASK bits be the offset in the line), and then we *could* just
> look things up using the btree method.
> 
> Al, do you have any clever ideas?

Umm...  One possibility would be something like fs/namespace.c:m_start() -
if nothing has changed since the last time, just use a cached pointer.
That has sped the damn thing (/proc/mounts et.al.) big way, but it's
dependent upon having an event count updated whenever we change the
mount tree - doing the same for vma_area list might or might not be
a good idea.  /proc/mounts and friends get ->poll() on that as well;
that probably would _not_ be a good idea in this case.

Re: Linux 4.9-rc6

[Linus Torvalds]

On Sun, Nov 20, 2016 at 2:27 PM, Eric Dumazet  wrote:
>
> Hosts with ~100,000 threads have an issue with /prov/vmallocinfo
>
> It can take about 800 usec to skip over ~100,000 struct vmap_area
> in s_start(), while holding vmap_area_lock spinlock, and therefore
> blocking fork()/pthread_create().
>
> I presume we can not switch to the rbtree (vmap_area_root)
> for /proc/vmallocinfo, because this file is seek-able, right ?

Well, the good news is that the file is root-only anyway, which means
that at least it won't have the issue that a lot of other /proc files
have had - namely being opened by random user programs or libraries.

Which means that the users of it are likely fairly limited.

Which in turn means that we can probably afford to play more games
with it. Including, for example, possibly marking it non-seekable.

Or even just limit the maximum entries we are willing to walk.

Or we could decide that that file shouldn't be a seq_file at all, use
the old "one page buffer" approach that was so common for /proc files,
and make the position encode the vmalloc address in it (make the lower
PAGE_MASK bits be the offset in the line), and then we *could* just
look things up using the btree method.

Al, do you have any clever ideas?

 Linus

Re: Linux 4.9-rc6

[Eric Dumazet]

On Sun, 2016-11-20 at 14:05 -0800, Linus Torvalds wrote:

> That said, nothing particular is bothering me all that much, but we've
> had some of the VMALLOC_STACK fixups continue to trickle in, so I
> worry that we're not quite done there yet. And let's see what
> Thorsten's regression list looks like next week. So no decision yet,
> it could still go either way.

Hosts with ~100,000 threads have an issue with /prov/vmallocinfo

It can take about 800 usec to skip over ~100,000 struct vmap_area
in s_start(), while holding vmap_area_lock spinlock, and therefore
blocking fork()/pthread_create().

I presume we can not switch to the rbtree (vmap_area_root)
for /proc/vmallocinfo, because this file is seek-able, right ?

Linux 4.9-rc6

[Linus Torvalds]

 mlxsw: spectrum_router: Ignore FIB notification events for
non-init namespaces

Johan Hovold (5):
  phy: fix device reference leaks
  net: ethernet: ti: cpsw: fix device and of_node leaks
  net: ethernet: ti: davinci_emac: fix device reference leak
  net: hns: fix device reference leaks
  mfd: core: Fix device reference leak in mfd_clone_cell

Johannes Berg (1):
  iwlwifi: pcie: mark command queue lock with separate lockdep class

John Allen (1):
  ibmvnic: Start completion queue negotiation at server-provided
optimum values

John W. Linville (1):
  netfilter: nf_tables: fix type mismatch with error return from
nft_parse_u32_check

Jonathan Liu (1):
  drm/sun4i: rgb: Enable panel after controller

Junzhi Zhao (3):
  drm/mediatek: do mtk_hdmi_send_infoframe after HDMI clock enable
  drm/mediatek: enhance the HDMI driving current
  drm/mediatek: modify the factor to make the pll_rate set in the
1G-2G range

Jérémy Lefaure (1):
  dmaengine: mmp_tdma: add missing select GENERIC_ALLOCATOR in Kconfig

Kan Liang (1):
  perf/x86/intel/uncore: Add more Intel uncore IMC PCI IDs for SkyLake

Keith Busch (1):
  nvme/pci: Don't free queues on error

Keno Fischer (1):
  gpio: Remove GPIO_DEVRES option

Krzysztof Blaszkowski (2):
  IB/hfi1: Return ENODEV for unsupported PCI device ids.
  IB/hfi1: Relocate rcvhdrcnt module parameter check.

LABBE Corentin (1):
  rtc: cmos: remove all __exit_p annotations

Lance Richardson (2):
  ipv4: allow local fragmentation in ip_finish_output_gso()
  ipv4: update comment to document GSO fragmentation cases.

Leon Romanovsky (1):
  IB/core: Set routable RoCE gid type for ipv4/ipv6 networks

Linus Torvalds (3):
  Revert "printk: make reading the kernel log flush pending lines"
  ASoC: lpass-platform: fix uninitialized variable
  Linux 4.9-rc6

Linus Walleij (5):
  video: ARM CLCD: fix Vexpress regression
  i2c: mux: fix up dependencies
  gpio: do not double-check direction on sleeping chips
  gpio: tc3589x: fix up .get_direction()
  mfd: stmpe: Fix RESET regression on STMPE2401

Liping Zhang (6):
  netfilter: nft_dynset: fix panic if NFT_SET_HASH is not enabled
  netfilter: nf_tables: fix *leak* when expr clone fail
  netfilter: nf_tables: fix race when create new element in dynset
  netfilter: nf_tables: destroy the set if fail to add transaction
  netfilter: nft_dup: do not use sreg_dev if the user doesn't specify it
  netfilter: nf_tables: fix oops when inserting an element into a
verdict map

Loic Pallardy (1):
  ARM: dts: STiH410-b2260: Fix typo in spi0 chipselect definition

Lokesh Vutla (1):
  rtc: omap: Fix selecting external osc

Luca Coelho (4):
  iwlwifi: mvm: use ssize_t for len in iwl_debugfs_mem_read()
  iwlwifi: mvm: fix d3_test with unified D0/D3 images
  iwlwifi: pcie: fix SPLC structure parsing
  iwlwifi: mvm: fix netdetect starting/stopping for unified images

Lukas Resch (1):
  can: sja1000: plx_pci: Add support for Moxa CAN devices

Lukas Wunner (1):
  x86/platform/intel-mid: Retrofit pci_platform_pm_ops ->get_state hook

Lv Zheng (1):
  tools/power/acpi: Remove direct kernel source include reference

Maciej Żenczykowski (1):
  net-ipv6: on device mtu change do not add mtu to mtu-less routes

Majd Dibbiny (1):
  IB/mlx5: Fix memory leak in query device

Maor Gottlieb (1):
  IB/mlx5: Validate requested RQT size

Marcelo Ricardo Leitner (1):
  sctp: assign assoc_id earlier in __sctp_connect

Marcin Wojtas (2):
  arm64: dts: marvell: fix clocksource for CP110 slave SPI0
  arm64: dts: marvell: add unique identifiers for Armada A8k SPI controllers

Marek Szyprowski (1):
  ARM: 8628/1: dma-mapping: preallocate DMA-debug hash tables in
core_initcall

Mario Kleiner (1):
  drm/amdgpu: Attach exclusive fence to prime exported bo's. (v5)

Mark Bloch (3):
  IB/cm: Mark stale CM id's whenever the mad agent was unregistered
  IB/core: Add missing check for addr_resolve callback return value
  IB/core: Avoid unsigned int overflow in sg_alloc_table

Mark Lord (1):
  r8152: Fix broken RX checksums.

Martin KaFai Lau (2):
  bpf: Fix bpf_redirect to an ipip/ip6tnl dev
  bpf: Add test for bpf_redirect to ipip/ip6tnl

Matan Barak (1):
  IB/mlx4: Fix create CQ error flow

Mathias Krause (1):
  rtnl: reset calcit fptr in rtnl_unregister()

Matt Fleming (1):
  x86/efi: Prevent mixed mode boot corruption with CONFIG_VMAP_STACK=y

Mauro Carvalho Chehab (1):
  gp8psk-fe: add missing MODULE_foo() macros

Max Filippov (2):
  xtensa: clean up printk usage for boot/crash logging
  xtensa: wire up new pkey_{mprotect,alloc,free} syscalls

Maxime Ripard (1):
  drm/sun4i: rgb: Remove the bridge enable/disable functions

Michael Chan (2):
  bnxt_en: Fix ring arithmetic in bnxt_setup_tc().
  bnxt_en: F

Re: Linux 4.9: Reported regressions as of Sunday, 2016-11-20

[Adam Borowski]

On Sun, Nov 20, 2016 at 04:09:51PM +0100, Thorsten Leemhuis wrote:
> Hi! Here is my fourth regression report for Linux 4.9.

> == Current regressions ==
> 
> Desc: builddeb: fix cross-building to arm64 producing host-arch debs
> Repo: 16-11-04 https://www.spinics.net/lists/linux-kbuild/msg13635.html
> Stat: 16-11-10 https://www.spinics.net/lists/linux-kbuild/msg13676.html
> Note: Looks stalled

There's a patch, acked by Riku Voipio, last version at
https://www.spinics.net/lists/linux-kbuild/msg13696.html
Michal: ping, does anything need to be done for merge?

> == Fixed since last report ==
> 
> Desc: module loadling broken due to kbuild changes
> Repo: 16-10-15 http://www.gossamer-threads.com/lists/linux/kernel/2544734
> Stat: Fixes 
> https://git.kernel.org/torvalds/c/4efca4ed05cbdfd13ec3e8cb623fb77d6e4ab187 
> https://git.kernel.org/torvalds/c/4efca4ed05cbdfd13ec3e8cb623fb77d6e4ab187

Not fixed yet, that pull merely allowed per-arch asm/asm-prototypes.h,
you need to actually provide those files on affected archs; patches for
x86 and arm exist.

-- 
A true bird-watcher waves his tail while doing so.

Linux 4.9: Reported regressions as of Sunday, 2016-11-20

[Thorsten Leemhuis]

Hi! Here is my fourth regression report for Linux 4.9. It lists 10
regressions I'm aware of. 6 of them are new; 11 got fixed (wow!)
since the last report -- that was two weeks ago, because I 
didn't find any spare time to compile a report last Sunday :-/

As always: Are you aware of any other regressions? Then please let me
know (simply CC regressi...@leemhuis.info). And please tell me if there
is anything in the report that shouldn't be there.

Ciao, Thorsten

== Current regressions ==

Desc: "irq 16: nobody cared (try booting with the ""irqpoll"" option) since 
t0b9e2988ab226 (ahci: use pci_alloc_irq_vectors)"
Repo: 16-11-19 https://bugzilla.kernel.org/show_bug.cgi?id=188181
Stat: n/a 
Note: new

Desc: [i.MX6 DRM IPUv3] Regression 4.9-rc5: greenish screen with YUV420 video
Repo: 16-11-17 https://www.spinics.net/lists/kernel/msg2385550.html
Stat: n/a 
Note: new

Desc: "oops due to 493b2ed3f760 (""crypto: algif_hash - Handle NULL hashes 
correctly"")"
Repo: 16-11-17 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1273867.html
Stat: 16-11-17 https://patchwork.kernel.org/patch/9434741/
Note: WIP, Patch available

Desc: MSI is no longer enabled for many/most Intel SATA controllers in 4.9
Repo: 16-11-16 https://bugzilla.kernel.org/show_bug.cgi?id=187821
Stat: 16-11-17 https://bugzilla.kernel.org/show_bug.cgi?id=187821#c3
Note: WIP, Patch available

Desc: "Failed boots bisected to 4cd13c21b207 ""softirq: Let ksoftirqd do its 
job"""
Repo: 16-11-16 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1273344.html
Stat: 16-11-18 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1275668.html
Note: WIP

Desc: qla2xxx: do not abort all commands in the adapter during EEH recovery
Repo: 16-11-14 
https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg55186.html
Stat: 16-11-14 
https://www.mail-archive.com/linux-scsi@vger.kernel.org/msg55198.html
Note: Fix heading mainline

Desc: builddeb: fix cross-building to arm64 producing host-arch debs
Repo: 16-11-04 https://www.spinics.net/lists/linux-kbuild/msg13635.html
Stat: 16-11-10 https://www.spinics.net/lists/linux-kbuild/msg13676.html
Note: Looks stalled

Desc: "build regression: make.cross ARCH=mips fails with ""No rule to make 
target 'alchemy/devboards/'. """
Repo: 16-10-30 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262410.html 
https://marc.info/?l=linux-kernel&m=147780880425626
Stat: n/a 
Note: nothing happened yet; BTW: Should build regressions be on this list at 
all?


== Stalled, waiting for feedback from reporter ==

Desc: 4.9-rc1 boot regression, ambiguous bisect result
Repo: 2016-10-19 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253369.html
Stat: 16-10-21 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1255296.html
Note: Waiting for Dan or someone else to look into this

Desc: Skylake gen6 suspend/resume video regression
Repo: 16-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177731 
https://bugs.freedesktop.org/show_bug.cgi?id=98517
Stat: 16-10-25 https://bugzilla.kernel.org/show_bug.cgi?id=177731#c3
Note: Stalled, poked bugzlla


== Going to be removed from the list ==

Desc: warning in intel_dp_aux_transfer: CPU: 0 PID: 4 at 
drivers/gpu/drm/i915/intel_dp.c:1062 intel_dp_aux_transfer+0x1ed/0x230#
Repo: 16-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177701
Stat: n/a 
Note: the warning seems to be fixed, but the problem that Martin saw might 
still be there; this will get a new entry in the regression list once confirmed

Desc: can't boot with root fs on md raid 0; mdadm: no devices listed in conf 
file were found. 
Repo: 2016-10-17 https://bugzilla.kernel.org/show_bug.cgi?id=178211
Stat: 16-11-03 https://bugzilla.kernel.org/show_bug.cgi?id=178211#c4
Note: sata adapters not detected, reporter is unable to debug and could need 
some help;


== Fixed since last report ==

Desc: """console: don't prefer first registered if DT specifies stdout-path"" 
breaks console on video outputs of various ARM boards; breaks some ppc machines 
as well"
Repo: 16-10-18 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1264523.html 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253391.html 
https://www.linux-mips.org/archives/linux-mips/2016-10/msg00176.html
Fix:  https://git.kernel.org/torvalds/c/c6c7d83b9c9e6a8b3e6d84c820ac61fbffc9e396

Desc: thinkpad x60, T40p: overheat with v4.9-rc4 (was Re: v4.8-rc1: thinkpad 
x60: running at low frequency even during kernel build)
Repo: 16-11-05 
https://www.mail-archive.com/ibm-acpi-devel@lists.sourceforge.net/msg03909.html 
https://bugzilla.kernel.org/show_bug.cgi?id=187311 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1264916.html
Fix:  https://git.kernel.org/torvalds/c/e2174b0c24caca170ca61eda2ae49c9

Re: Linux 4.9-rc4 double free from pp_release()

[Shuah Khan]

On 11/09/2016 03:59 PM, Sudip Mukherjee wrote:
> Hi Shuah
> 
> On Wednesday 09 November 2016 10:04 PM, Shuah Khan wrote:
>> Hi Sudip/Greg,
>>
>> I am seeing the following double free from pp_release() in Linux 4.9-rc4
>> Is this a known problem?
> 
> Can you please check if the patch at [1] fixes the problem.
> 
> [1] https://patchwork.kernel.org/patch/9404815/
> 
> 
> Regards
> Sudip
> 
> 

Hi Sudip,

Yes the above patch fixed the problem. I tested it on 4.9-rc5

thanks,
-- Shuah

Linux 4.9-rc5

[Linus Torvalds]

ls
  ASoC: sun4i-codec: Enable bus clock after getting GPIO

Chris Wilson (3):
  drm/i915: Round tile chunks up for constructing partial VMAs
  drm/i915: Limit Valleyview and earlier to only using mappable scanout
  lib/stackdepot: export save/fetch stack for drivers

Christian König (2):
  drm/amd: fix scheduler fence teardown order v2
  drm/amdgpu: add some error handling to amdgpu_init v2

Christoph Hellwig (3):
  aio: hold an extra file reference over AIO read/write operations
  fs: remove the never implemented aio_fsync file operation
  fs: remove aio_run_iocb

Christophe JAILLET (1):
  nbd: Fix error handling

Chuck Lever (1):
  xprtrdma: Fix DMAR failure in frwr_op_map() after reconnect

Colin Ian King (1):
  hwmon: (core) fix resource leak on devm_kcalloc failure

Dan Carpenter (1):
  ASoC: rt5663: fix a debug statement

Darrick J. Wong (1):
  xfs: defer should abort intent items if the trans roll fails

Dave Airlie (1):
  drm/udl: make control msg static const. (v2)

David Jeffery (1):
  scsi: vmw_pvscsi: return SUCCESS for successful command aborts

David Lechner (1):
  usb: musb: da8xx: Don't print phy error on -EPROBE_DEFER

Dhinakaran Pandiyan (2):
  drm/i915/dp: BDW cdclk fix for DP audio
  drm/i915/dp: Extend BDW DP audio workaround to GEN9 platforms

Emil Lundmark (1):
  clk: imx: fix integer overflow in AV PLL round rate

Eryu Guan (2):
  mm/filemap: don't allow partially uptodate page for pipes
  mm/filemap: don't allow partially uptodate page for pipes

Even Xu (3):
  HID: intel-ish-hid: consolidate ish wake up operation
  HID: intel-ish-hid: Move DMA disable code to new function
  HID: intel-ish-hid: Fix driver reinit failure

Fabio Estevam (1):
  mmc: mxs: Initialize the spinlock prior to using it

Felipe Balbi (2):
  usb: dwc3: st: add missing  include
  usb: gadget: u_ether: remove interrupt throttling

Grazvydas Ignotas (1):
  drm/amd/powerplay: don't succeed in getters if fan is missing

Greg Thelen (1):
  memcg: prevent memcg caches to be both OFF_SLAB & OBJFREELIST_SLAB

Guenter Roeck (1):
  openrisc: Define __ro_after_init to avoid crash

Hans de Goede (1):
  Revert "console: don't prefer first registered if DT specifies
stdout-path"

Heikki Krogerus (1):
  ACPI / platform: Add support for build-in properties

Heiko Carstens (1):
  percpu: use notrace variant of preempt_disable/preempt_enable

Huacai Chen (1):
  staging: sm750fb: Fix bugs introduced by early commits

Hugh Dickins (1):
  shmem: fix pageflags after swapping DMA32 object

Ian Abbott (1):
  staging: comedi: ni_tio: fix buggy ni_tio_clock_period_ps() return value

Icenowy Zheng (1):
  phy: sun4i: check PMU presence when poking unknown bit of pmu

Ilya Dryomov (1):
  libceph: initialize last_linger_id with a large integer

Jaehoon Chung (2):
  Documentation: synopsys-dw-mshc: add binding for reset-names
  mmc: dw_mmc: add the "reset" as name of reset controller

Jakub Kicinski (1):
  mm: kmemleak: scan .data.ro_after_init

Jan Kara (1):
  aio: fix freeze protection of aio writes

Jann Horn (2):
  ppdev: fix double-free of pp->pdev->name
  swapfile: fix memory corruption via malformed swapfile

Jens Axboe (1):
  aoe: fix crash in page count manipulation

Joerg Roedel (1):
  iommu/vt-d: Fix dead-locks in disable_dmar_iommu() path

Johan Hovold (4):
  uwb: fix device reference leaks
  PM / sleep: fix device reference leak in test_suspend
  staging: greybus: arche-platform: fix device reference leak
  USB: cdc-acm: fix TIOCMIWAIT

Jon Medhurst (Tixy) (1):
  ASoC: hdmi-codec: Fix hdmi_of_xlate_dai_name when #sound-dai-cells = <0>

Junxiao Bi (1):
  ocfs2: fix not enough credit panic

Keith Busch (1):
  PCI: VMD: Update filename to reflect move

Kirill Esipov (1):
  usb: musb: remove duplicated actions

Larry Finger (1):
  drm/radeon: Fix kernel panic on shutdown

Laura Abbott (2):
  clk: xgene: Don't call __pa on ioremaped address
  cpupower: Correct return type of cpu_power_is_cpu_online() in cpufreq-set

Linus Torvalds (1):
  Linux 4.9-rc5

Lorenzo Bianconi (1):
  iio: st_sensors: fix scale configuration for h3lis331dl

Lucas Stach (1):
  drm/imx: disable planes before DC

Lukas Wunner (1):
  ASoC: Intel: Skylake: Always acquire runtime pm ref on unload

Lyude (1):
  drm/i915/vlv: Prevent enabling hpd polling in late suspend

Marc Dietrich (1):
  staging: nvec: remove managed resource from PS2 driver

Marc Zyngier (1):
  arm/arm64: KVM: Perform local TLB invalidation when multiplexing
vcpus on a single CPU

Marek Szyprowski (2):
  clk/samsung: Use CLK_OF_DECLARE_DRIVER initialization method for CLKOUT
  ASoC: samsung: get access to DMA engine early to defer probe properly

Mark Brown (1):
 

Re: Linux 4.9-rc4 double free from pp_release()

[Sudip Mukherjee]

Hi Shuah

On Wednesday 09 November 2016 10:04 PM, Shuah Khan wrote:

Hi Sudip/Greg,

I am seeing the following double free from pp_release() in Linux 4.9-rc4
Is this a known problem?


Can you please check if the patch at [1] fixes the problem.

[1] https://patchwork.kernel.org/patch/9404815/


Regards
Sudip

Linux 4.9-rc4 double free from pp_release()

[Shuah Khan]

Hi Sudip/Greg,

I am seeing the following double free from pp_release() in Linux 4.9-rc4
Is this a known problem?

-- Shuah

[   54.732175] device: 'ppdev0.0': device_add
[   54.732220] bus: 'parport': add device ppdev0.0
[   54.732388] PM: Adding info for parport:ppdev0.0
[   54.732804] bus: 'parport': driver_probe_device: matched device
ppdev0.0 with driver ppdev
[   54.732810] bus: 'parport': really_probe: probing driver ppdev with
device ppdev0.0
[   54.732851] devices_kset: Moving ppdev0.0 to end of list
[   54.732857] driver: 'ppdev': driver_bound: bound to device 'ppdev0.0'
[   54.732872] bus: 'parport': really_probe: bound device ppdev0.0 to
driver ppdev
[   54.785001] device: 'ppdev0.0': device_unregister
[   54.785133] bus: 'parport': remove device ppdev0.0
[   54.785161] PM: Removing info for parport:ppdev0.0
[   54.785315] 
==
[   54.785326] BUG: Double free or freeing an invalid pointer
[   54.785332] Unexpected shadow byte: 0xFB
[   54.785344] CPU: 1 PID: 973 Comm: colord-sane Tainted: GB   W
4.9.0-rc4+ #1
[   54.785348] Hardware name: Hewlett-Packard HP ProBook 6475b/180F,
BIOS 68TTU Ver. F.04 08/03/2012
[   54.785353]  8801f6197d20 81b372e3 8801fa403cc0
8801b1f15048
[   54.785367]  8801f6197d48 8156bf71 fffb
8801fa403cc0
[   54.785378]  8801b1f15048 8801f6197d78 8156c8e9
0296
[   54.785387] Call Trace:
[   54.785402]  [] dump_stack+0x67/0x94
[   54.785411]  [] kasan_object_err+0x21/0x70
[   54.785417]  [] kasan_report_double_free+0x49/0x60
[   54.785424]  [] kasan_slab_free+0x9b/0xb0
[   54.785431]  [] kfree+0xd9/0x280
[   54.785443]  [] pp_release+0x1db/0xa00 [ppdev]
[   54.785451]  [] __fput+0x24b/0x690
[   54.785459]  [] fput+0xe/0x10
[   54.785466]  [] task_work_run+0xde/0x140
[   54.785474]  [] exit_to_usermode_loop+0xf1/0x110
[   54.785483]  [] syscall_return_slowpath+0x150/0x190
[   54.785491]  [] entry_SYSCALL_64_fastpath+0xab/0xad
[   54.785497] Object at 8801b1f15048, in cache kmalloc-8 size: 8
[   54.785503] Allocated:
[   54.785510] PID = 973
[   54.785517]
[   54.785524] [] save_stack_trace+0x1b/0x20
[   54.785527]
[   54.785533] [] save_stack+0x46/0xd0
[   54.785535]
[   54.785541] [] kasan_kmalloc+0xad/0xe0
[   54.785543]
[   54.785549] [] kasan_slab_alloc+0x12/0x20
[   54.785551]
[   54.785558] [] __kmalloc_track_caller+0xd5/0x290
[   54.785560]
[   54.785567] [] kstrdup+0x31/0x60
[   54.785569]
[   54.785583] []
parport_register_dev_model+0x226/0xe20 [parport]
[   54.785585]
[   54.785593] [] register_device+0x115/0x210 [ppdev]
[   54.785596]
[   54.785604] [] pp_ioctl+0xec1/0x20a0 [ppdev]
[   54.785606]
[   54.785612] [] do_vfs_ioctl+0x184/0xf30
[   54.785614]
[   54.785620] [] SyS_ioctl+0x79/0x90
[   54.785622]
[   54.785628] [] entry_SYSCALL_64_fastpath+0x18/0xad
[   54.785631] Freed:
[   54.785636] PID = 973
[   54.785641]
[   54.785647] [] save_stack_trace+0x1b/0x20
[   54.785649]
[   54.785655] [] save_stack+0x46/0xd0
[   54.785657]
[   54.785664] [] kasan_slab_free+0x71/0xb0
[   54.785667]
[   54.785672] [] kfree+0xd9/0x280
[   54.785676]
[   54.785686] [] free_pardevice+0x34/0x50 [parport]
[   54.785689]
[   54.785696] [] device_release+0x76/0x1e0
[   54.785698]
[   54.785706] [] kobject_release+0x107/0x370
[   54.785707]
[   54.785714] [] kobject_put+0x4e/0xa0
[   54.785716]
[   54.785722] [] device_unregister+0x66/0xa0
[   54.785725]
[   54.785736] []
parport_unregister_device+0x3d4/0x670 [parport]
[   54.785738]
[   54.785747] [] pp_release+0x1d3/0xa00 [ppdev]
[   54.785749]
[   54.785755] [] __fput+0x24b/0x690
[   54.785757]
[   54.785763] [] fput+0xe/0x10
[   54.785765]
[   54.785771] [] task_work_run+0xde/0x140
[   54.785773]
[   54.785778] [] exit_to_usermode_loop+0xf1/0x110
[   54.785780]
[   54.785786] [] syscall_return_slowpath+0x150/0x190
[   54.785788]
[   54.785795] [] entry_SYSCALL_64_fastpath+0xab/0xad
[   54.785798] 
==

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Mittwoch, 9. November 2016, 11:42:36 CET schrieb Jani Nikula:
> > *However*, I got a soft freeze and a hard freeze (well after about a
> > minute I gave up and rebooted by pressing power button long enough to
> > forcefully switch off the laptop) when playing PlaneShift using
> > drm-intel-fixes branch.
> > 
> > Unfortunately I have no further time to debug any of this week, but it
> > seems not all fixes are there are ready for next stable kernel.
> 
> Current drm-intel-fixes is just six commits on top of -rc4, and it's
> very hard for me to believe any of those would cause the symptoms you
> see. I presume the problem, whatever it is, is already in -rc4.
> 
> That, of course, is not a happy thing per se, but please don't block the
> current batch of fixes by making unsubstantiated claims. Please do file
> a bug about that issue over at [1] so we don't hijack this thread.

You are right. I have no comparison with 4.9-rc4 due to the graphics glitches 
I had in it.

-- 
Martin

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Jani Nikula]

On Wed, 09 Nov 2016, Martin Steigerwald  wrote:
> Also no graphics glitches with external DisplayPort connected display.

Thanks for confirming this. The fix should make it to -rc5.

> *However*, I got a soft freeze and a hard freeze (well after about a
> minute I gave up and rebooted by pressing power button long enough to
> forcefully switch off the laptop) when playing PlaneShift using
> drm-intel-fixes branch.
>
> Unfortunately I have no further time to debug any of this week, but it
> seems not all fixes are there are ready for next stable kernel.

Current drm-intel-fixes is just six commits on top of -rc4, and it's
very hard for me to believe any of those would cause the symptoms you
see. I presume the problem, whatever it is, is already in -rc4.

That, of course, is not a happy thing per se, but please don't block the
current batch of fixes by making unsubstantiated claims. Please do file
a bug about that issue over at [1] so we don't hijack this thread.

Thanks,
Jani.


[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Dienstag, 8. November 2016, 16:17:59 CET schrieb Martin Steigerwald:
> Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald:
> > Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> > > On Mon, 07 Nov 2016, Martin Steigerwald  wrote:
> > > > It is also the same kind of corruptions as shown in
> > > > 
> > > > [Bug 177701] warning in intel_dp_aux_transfer
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > > > 
> > > > Just compare
> > > > 
> > > > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > > > 
> > > > with
> > > > 
> > > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.p
> > > > ng
> > > > 
> > > > 
> > > > However that bug report links to
> > > > 
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > > > 
> > > > yet the patch mentioned in there does not fix the issue. So I wonder
> > > > whether bug #97344 and bug #177701 are really the same.
> > > 
> > > They are the same, it's just that #177701 conflates two issues, a
> > > warning (tracked at fdo #973449) and a graphics corruption. The latter
> > > appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> > > 
> > > The fix has now been pushed to drm-intel-fixes branch of
> > > http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> > > latest fixes. Please try that and report back.
> > 
> > For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes
> 
> I ment not exactly this commit, but this is the last commit in the branch as
> I compiled the kernel.
> 
> > branch seems to work okay. I can only test with laptop display at the
> > moment. But I will test with external display this evening – in case the
> > issue at hand is DisplayPort related.

Also no graphics glitches with external DisplayPort connected display.

*However*, I got a soft freeze and a hard freeze (well after about a minute I 
gave up and rebooted by pressing power button long enough to forcefully switch 
off the laptop) when playing PlaneShift using drm-intel-fixes branch.

Unfortunately I have no further time to debug any of this week, but it seems 
not all fixes are there are ready for next stable kernel.

Ciao,
Martin

> > I will add this information to fdo bug 98402 as well.
> > 
> > Thanks,
> > Martin
> > 
> > > > Of course I can report a bug at fdo as well, but I am a bit confused
> > > > whether it may not already have been reported. Well I hope I get a
> > > > chance to report it there as well and you get to decide.
> > > 
> > > If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> > > bug over at the freedesktop.org bugzilla.
> > > 
> > > BR,
> > > Jani.


-- 
Martin

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Dienstag, 8. November 2016, 16:11:31 CET schrieb Martin Steigerwald:
> Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> > On Mon, 07 Nov 2016, Martin Steigerwald  wrote:
> > > It is also the same kind of corruptions as shown in
> > > 
> > > [Bug 177701] warning in intel_dp_aux_transfer
> > > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > > 
> > > Just compare
> > > 
> > > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > > 
> > > with
> > > 
> > > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > > 
> > > 
> > > However that bug report links to
> > > 
> > > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > > 
> > > yet the patch mentioned in there does not fix the issue. So I wonder
> > > whether bug #97344 and bug #177701 are really the same.
> > 
> > They are the same, it's just that #177701 conflates two issues, a
> > warning (tracked at fdo #973449) and a graphics corruption. The latter
> > appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> > 
> > The fix has now been pushed to drm-intel-fixes branch of
> > http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> > latest fixes. Please try that and report back.
> 
> For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes

I ment not exactly this commit, but this is the last commit in the branch as I 
compiled the kernel.

> branch seems to work okay. I can only test with laptop display at the
> moment. But I will test with external display this evening – in case the
> issue at hand is DisplayPort related.
> 
> I will add this information to fdo bug 98402 as well.
> 
> Thanks,
> Martin
> 
> > > Of course I can report a bug at fdo as well, but I am a bit confused
> > > whether it may not already have been reported. Well I hope I get a
> > > chance to report it there as well and you get to decide.
> > 
> > If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> > bug over at the freedesktop.org bugzilla.
> > 
> > BR,
> > Jani.


-- 
Martin

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> On Mon, 07 Nov 2016, Martin Steigerwald  wrote:
> > It is also the same kind of corruptions as shown in
> > 
> > [Bug 177701] warning in intel_dp_aux_transfer
> > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > 
> > Just compare
> > 
> > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > 
> > with
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > 
> > However that bug report links to
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > 
> > yet the patch mentioned in there does not fix the issue. So I wonder
> > whether bug #97344 and bug #177701 are really the same.
> 
> They are the same, it's just that #177701 conflates two issues, a
> warning (tracked at fdo #973449) and a graphics corruption. The latter
> appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> 
> The fix has now been pushed to drm-intel-fixes branch of
> http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> latest fixes. Please try that and report back.

For now commit 54905ab5fe7aa453610e31cec640e528aaedb2e2 of drm-intel-fixes 
branch seems to work okay. I can only test with laptop display at the moment. 
But I will test with external display this evening – in case the issue at hand 
is DisplayPort related.

I will add this information to fdo bug 98402 as well.

Thanks,
Martin

> > Of course I can report a bug at fdo as well, but I am a bit confused
> > whether it may not already have been reported. Well I hope I get a
> > chance to report it there as well and you get to decide.
> 
> If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> bug over at the freedesktop.org bugzilla.
> 
> BR,
> Jani.


-- 
Martin

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Montag, 7. November 2016, 19:09:36 CET schrieb Jani Nikula:
> On Mon, 07 Nov 2016, Martin Steigerwald  wrote:
> > It is also the same kind of corruptions as shown in
> > 
> > [Bug 177701] warning in intel_dp_aux_transfer
> > https://bugzilla.kernel.org/show_bug.cgi?id=177701
> > 
> > Just compare
> > 
> > https://bugzilla.kernel.org/attachment.cgi?id=241801
> > 
> > with
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > 
> > However that bug report links to
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=97344
> > 
> > yet the patch mentioned in there does not fix the issue. So I wonder
> > whether bug #97344 and bug #177701 are really the same.
> 
> They are the same, it's just that #177701 conflates two issues, a
> warning (tracked at fdo #973449) and a graphics corruption. The latter
> appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.
> 
> The fix has now been pushed to drm-intel-fixes branch of
> http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
> latest fixes. Please try that and report back.

Thanks for clearing that up, Jani.

I think I get a chance to compile from drm-intel tomorrow and test it. If it 
just happens on external displays – I didn´t actually check this – I can only 
test it in the evening.
 
> > Of course I can report a bug at fdo as well, but I am a bit confused
> > whether it may not already have been reported. Well I hope I get a
> > chance to report it there as well and you get to decide.
> 
> If drm-intel-fixes doesn't fix the issue for you, please file a *new*
> bug over at the freedesktop.org bugzilla.

Will do.

Thanks,
-- 
Martin

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Jani Nikula]

On Mon, 07 Nov 2016, Martin Steigerwald  wrote:
> It is also the same kind of corruptions as shown in
>
> [Bug 177701] warning in intel_dp_aux_transfer
> https://bugzilla.kernel.org/show_bug.cgi?id=177701
>
> Just compare
>
> https://bugzilla.kernel.org/attachment.cgi?id=241801
>
> with 
>
> https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
>
>
> However that bug report links to
>
> https://bugs.freedesktop.org/show_bug.cgi?id=97344
>
> yet the patch mentioned in there does not fix the issue. So I wonder whether 
> bug #97344 and bug #177701 are really the same.

They are the same, it's just that #177701 conflates two issues, a
warning (tracked at fdo #973449) and a graphics corruption. The latter
appears to be https://bugs.freedesktop.org/show_bug.cgi?id=98402.

The fix has now been pushed to drm-intel-fixes branch of
http://cgit.freedesktop.org/drm-intel, which is -rc4 plus half a dozen
latest fixes. Please try that and report back.

> Of course I can report a bug at fdo as well, but I am a bit confused
> whether it may not already have been reported. Well I hope I get a
> chance to report it there as well and you get to decide.

If drm-intel-fixes doesn't fix the issue for you, please file a *new*
bug over at the freedesktop.org bugzilla.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Montag, 7. November 2016, 13:04:16 CET schrieb Jani Nikula:
> On Sun, 06 Nov 2016, Martin Steigerwald  wrote:
> > Hi.
> > 
> > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> >> So it's once again a Saturday afternoon rather than Sunday, this time
> >> because I felt this rc was already big enough.
> > 
> > With kernel 4.9-rc4 I saw gfx corruptions like
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> 
> Is this the same issue or a different issue from [1]? Since you mention
> -rc4, was this introduced in -rc4, or earlier?

Yes, the gfx corruption look similar. So I bet it is the same issue as in [1].


It is also the same kind of corruptions as shown in

[Bug 177701] warning in intel_dp_aux_transfer
https://bugzilla.kernel.org/show_bug.cgi?id=177701

Just compare

https://bugzilla.kernel.org/attachment.cgi?id=241801

with 

https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png


However that bug report links to

https://bugs.freedesktop.org/show_bug.cgi?id=97344

yet the patch mentioned in there does not fix the issue. So I wonder whether 
bug #97344 and bug #177701 are really the same.

> Please file a bug over at [2]. One issue per bug if this is different
> from [1].

As #177701 seem to have the same corruptions, yet I do not have any

merkaba:~#1> zgrep intel_dp_aux_transfer /var/log/kern.log*
merkaba:~#1>

Of course I can report a bug at fdo as well, but I am a bit confused whether 
it may not already have been reported. Well I hope I get a chance to report it 
there as well and you get to decide.

Thank you,
Martin

> [1] http://lkml.kernel.org/r/20161031215454.gb3...@suse.de
> [2]
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
> > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to
> > the
> > point of not being able to use these applications in a meaningful way.
> > 
> > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet
> > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx
> > glitches like that anymore.
> > 
> > Anything known about this?
> > 
> > Machine is ThinkPad T520 with Sandybridge graphics.
> > 
> > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> > 
> > Next week and weekend will be pretty busy and this is a production
> > machine, so bisection or any other time-consuming work on this is out of
> > question for me. I can provide additional details in case they are easy
> > and quick enough to obtain.
> > 
> > 
> > System information (now back on 4.8 kernel):
> > 
> > # phoronix-test-suite system-info
> > 
> > Phoronix Test Suite v5.2.1
> > System Information
> > 
> > Hardware:
> > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
> > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB,
> > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd
> > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED,
> > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> > 
> > Software:
> > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE
> > Frameworks 5, Display Server: X Server 1.18.4, Display Driver:
> > modesetting 1.18.4, OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0
> > 20161103, File-System: btrfs, Screen Resolution: 3840x1080
> > 
> > 
> > # apt-show-versions | egrep
> > "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> > core)" | grep amd64
> > libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> > 
> > 
> > Excerpt of glxinfo:
> > 
> > Extended renderer info (GLX_MESA_query_renderer):
> > Vendor: Intel Open Source Technology Center (0x8086)
> > Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> > Version: 12.0.3
> > Accelerated: yes
> > Video memory: 1536MB
> > Unified memory: yes
> > Preferred profile: core (0x1)
> > Max core profile version: 3.3
> > Max compat profile version: 3.0
> > Max GLES1 profile version: 1.1
> > Max GLES[23] profile version: 3.0
> > 
> > X.org runs with modesetting driver (default was changed in Debian Sid a
> > while back).
> > 
> > Thanks,
> > ___
> > Intel-gfx mailing list
> > intel-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx


-- 
Martin

Re: [Intel-gfx] [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Jani Nikula]

On Sun, 06 Nov 2016, Martin Steigerwald  wrote:
> Hi.
>
> Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
>> So it's once again a Saturday afternoon rather than Sunday, this time
>> because I felt this rc was already big enough.
>
> With kernel 4.9-rc4 I saw gfx corruptions like
>
> https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png

Is this the same issue or a different issue from [1]? Since you mention
-rc4, was this introduced in -rc4, or earlier?

Please file a bug over at [2]. One issue per bug if this is different
from [1].

BR,
Jani.


[1] http://lkml.kernel.org/r/20161031215454.gb3...@suse.de
[2] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel


>
> in Konversation, Konsole, Akregator and other KDE/Qt related apps up to the 
> point of not being able to use these applications in a meaningful way.
>
> I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet 
> after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx 
> glitches like that anymore.
>
> Anything known about this?
>
> Machine is ThinkPad T520 with Sandybridge graphics.
>
> Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
>
> Next week and weekend will be pretty busy and this is a production machine, 
> so 
> bisection or any other time-consuming work on this is out of question for me. 
> I can provide additional details in case they are easy and quick enough to 
> obtain.
>
>
> System information (now back on 4.8 kernel):
>
> # phoronix-test-suite system-info
>
> Phoronix Test Suite v5.2.1
> System Information
>
> Hardware:
> Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
> 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
> Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd 
> Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, 
> Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
>
> Software:
> OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE Frameworks 
> 5, Display Server: X Server 1.18.4, Display Driver: modesetting 1.18.4, 
> OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0 20161103, File-System: btrfs, 
> Screen Resolution: 3840x1080
>
>
> # apt-show-versions | egrep "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> core)" | grep amd64
> libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
>
>
> Excerpt of glxinfo:
>
> Extended renderer info (GLX_MESA_query_renderer):
> Vendor: Intel Open Source Technology Center (0x8086)
> Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> Version: 12.0.3
> Accelerated: yes
> Video memory: 1536MB
> Unified memory: yes
> Preferred profile: core (0x1)
> Max core profile version: 3.3
> Max compat profile version: 3.0
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.0
>
> X.org runs with modesetting driver (default was changed in Debian Sid a while 
> back).
>
> Thanks,
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Technology Center

Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Sonntag, 6. November 2016, 17:25:15 CET schrieb Mihai Donțu:
> On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote:
> > Hi.
> > 
> > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> > > So it's once again a Saturday afternoon rather than Sunday, this time
> > > because I felt this rc was already big enough.
> > 
> > With kernel 4.9-rc4 I saw gfx corruptions like
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to
> > the
> > point of not being able to use these applications in a meaningful way.
> > 
> > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet
> > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx
> > glitches like that anymore.
> > 
> > Anything known about this?
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=177701
> 
> The proposed patch appears to be:
> https://patchwork.freedesktop.org/patch/116808/
> 
> Have not tested it yet.

This patch does not fix the issue for me. Still the same graphical glitches.

Thanks,
Martin

> > Machine is ThinkPad T520 with Sandybridge graphics.
> > 
> > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> > 
> > Next week and weekend will be pretty busy and this is a production
> > machine, so bisection or any other time-consuming work on this is out of
> > question for me. I can provide additional details in case they are easy
> > and quick enough to obtain.
> > 
> > 
> > System information (now back on 4.8 kernel):
> > 
> > # phoronix-test-suite system-info
> > 
> > Phoronix Test Suite v5.2.1
> > System Information
> > 
> > Hardware:
> > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
> > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB,
> > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd
> > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED,
> > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> > 
> > Software:
> > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE
> > Frameworks 5, Display Server: X Server 1.18.4, Display Driver:
> > modesetting 1.18.4, OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0
> > 20161103, File-System: btrfs, Screen Resolution: 3840x1080
> > 
> > 
> > # apt-show-versions | egrep
> > "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> > core)" | grep amd64
> > libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> > 
> > 
> > Excerpt of glxinfo:
> > 
> > Extended renderer info (GLX_MESA_query_renderer):
> > Vendor: Intel Open Source Technology Center (0x8086)
> > Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> > Version: 12.0.3
> > Accelerated: yes
> > Video memory: 1536MB
> > Unified memory: yes
> > Preferred profile: core (0x1)
> > Max core profile version: 3.3
> > Max compat profile version: 3.0
> > Max GLES1 profile version: 1.1
> > Max GLES[23] profile version: 3.0
> > 
> > X.org runs with modesetting driver (default was changed in Debian Sid a
> > while back).


-- 
Martin

Re: Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

[Tobias Klausmann]

On 05.11.2016 23:38, Gabriel C wrote:

Hello ,


I've tested 4.9-rcX and Linus git tree and have on this box the following 
messages :

.

Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks:
Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu_node (CPUs 
0-15): P0
Nov 05 20:26:40 zwerg kernel: (detected by 8, t=60002 jiffies, g=2426, 
c=2425, q=789)
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe

.

When I boot to console mode the system seems to work at least when I'm loggen 
in from tty1.
Switching to other tty's sometimes works sometimes not.. Starting X makes the 
box hang.. sddm starts but I
never get to the logn screen. After some minutes I have to hard reset the box..

Latest tested git kernel is 4.9.0-rc3-00429-g03daa36 , the box is a FUJITSU 
PRIMERGY TX200 S5.

config used and dmesg can be found there :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/

Best Regards

Gabriel C


Hi,
i'm witnessing stalls as well (with different stack traces though: [1], 
[2], [3], [4]). Silly enough this seems to happen _only_ at my 
university with wifi enabled (works fine with older kernels: tested 
4.8.4 and older ones as they were recent).


Best Regards,
Tobias Klausmann

[1]: https://homepages.thm.de/~tjkl80/dmesg4.txt
[2]: https://homepages.thm.de/~tjkl80/dmesg3.txt
[3]: https://homepages.thm.de/~tjkl80/dmesg2.txt
[4]: https://homepages.thm.de/~tjkl80/dmesg.txt

Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Am Sonntag, 6. November 2016, 17:25:15 CET schrieb Mihai Donțu:
> On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote:
> > Hi.
> > 
> > Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> > > So it's once again a Saturday afternoon rather than Sunday, this time
> > > because I felt this rc was already big enough.
> > 
> > With kernel 4.9-rc4 I saw gfx corruptions like
> > 
> > https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> > 
> > in Konversation, Konsole, Akregator and other KDE/Qt related apps up to
> > the
> > point of not being able to use these applications in a meaningful way.
> > 
> > I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet
> > after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx
> > glitches like that anymore.
> > 
> > Anything known about this?
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=177701
> 
> The proposed patch appears to be:
> https://patchwork.freedesktop.org/patch/116808/
> 
> Have not tested it yet.

Thank you.

It applies cleanly. I think I get a chance to test it this week.

Thanks,
Martin

> > Machine is ThinkPad T520 with Sandybridge graphics.
> > 
> > Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> > 
> > Next week and weekend will be pretty busy and this is a production
> > machine, so bisection or any other time-consuming work on this is out of
> > question for me. I can provide additional details in case they are easy
> > and quick enough to obtain.
> > 
> > 
> > System information (now back on 4.8 kernel):
> > 
> > # phoronix-test-suite system-info
> > 
> > Phoronix Test Suite v5.2.1
> > System Information
> > 
> > Hardware:
> > Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO
> > 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB,
> > Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd
> > Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED,
> > Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> > 
> > Software:
> > OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE
> > Frameworks 5, Display Server: X Server 1.18.4, Display Driver:
> > modesetting 1.18.4, OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0
> > 20161103, File-System: btrfs, Screen Resolution: 3840x1080
> > 
> > 
> > # apt-show-versions | egrep
> > "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> > core)" | grep amd64
> > libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> > libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> > xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> > 
> > 
> > Excerpt of glxinfo:
> > 
> > Extended renderer info (GLX_MESA_query_renderer):
> > Vendor: Intel Open Source Technology Center (0x8086)
> > Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> > Version: 12.0.3
> > Accelerated: yes
> > Video memory: 1536MB
> > Unified memory: yes
> > Preferred profile: core (0x1)
> > Max core profile version: 3.3
> > Max compat profile version: 3.0
> > Max GLES1 profile version: 1.1
> > Max GLES[23] profile version: 3.0
> > 
> > X.org runs with modesetting driver (default was changed in Debian Sid a
> > while back).


-- 
Martin

Re: [REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Mihai Donțu]

On Sun, 06 Nov 2016 15:48:36 +0100 Martin Steigerwald wrote:
> Hi.
> 
> Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> > So it's once again a Saturday afternoon rather than Sunday, this time
> > because I felt this rc was already big enough.  
> 
> With kernel 4.9-rc4 I saw gfx corruptions like
> 
> https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png
> 
> in Konversation, Konsole, Akregator and other KDE/Qt related apps up to the 
> point of not being able to use these applications in a meaningful way.
> 
> I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet 
> after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx 
> glitches like that anymore.
> 
> Anything known about this?

https://bugzilla.kernel.org/show_bug.cgi?id=177701

The proposed patch appears to be:
https://patchwork.freedesktop.org/patch/116808/

Have not tested it yet.

> Machine is ThinkPad T520 with Sandybridge graphics.
> 
> Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.
> 
> Next week and weekend will be pretty busy and this is a production machine, 
> so 
> bisection or any other time-consuming work on this is out of question for me. 
> I can provide additional details in case they are easy and quick enough to 
> obtain.
> 
> 
> System information (now back on 4.8 kernel):
> 
> # phoronix-test-suite system-info
> 
> Phoronix Test Suite v5.2.1
> System Information
> 
> Hardware:
> Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
> 42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
> Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd 
> Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, 
> Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205
> 
> Software:
> OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE Frameworks 
> 5, Display Server: X Server 1.18.4, Display Driver: modesetting 1.18.4, 
> OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0 20161103, File-System: btrfs, 
> Screen Resolution: 3840x1080
> 
> 
> # apt-show-versions | egrep "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
> core)" | grep amd64
> libdrm-intel1:amd64/sid 2.4.71-1 uptodate
> libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
> xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate
> 
> 
> Excerpt of glxinfo:
> 
> Extended renderer info (GLX_MESA_query_renderer):
> Vendor: Intel Open Source Technology Center (0x8086)
> Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
> Version: 12.0.3
> Accelerated: yes
> Video memory: 1536MB
> Unified memory: yes
> Preferred profile: core (0x1)
> Max core profile version: 3.3
> Max compat profile version: 3.0
> Max GLES1 profile version: 1.1
> Max GLES[23] profile version: 3.0
> 
> X.org runs with modesetting driver (default was changed in Debian Sid a while 
> back).

-- 
Mihai Donțu

[REGRESSION] Linux 4.9-rc4: gfx glitches on Intel Sandybridge (was: Re: Linux 4.9-rc4)

[Martin Steigerwald]

Hi.

Am Samstag, 5. November 2016, 16:46:33 CET schrieb Linus Torvalds:
> So it's once again a Saturday afternoon rather than Sunday, this time
> because I felt this rc was already big enough.

With kernel 4.9-rc4 I saw gfx corruptions like

https://martin-steigerwald.de/tmp/display-issues-with-kernel-4.9-rc4.png

in Konversation, Konsole, Akregator and other KDE/Qt related apps up to the 
point of not being able to use these applications in a meaningful way.

I first thought this might be due to upgrading Qt from 5.6.1 to 5.7.1, yet 
after rebooting into 4.8 Linux kernel as packaged in Debian I saw no gfx 
glitches like that anymore.

Anything known about this?

Machine is ThinkPad T520 with Sandybridge graphics.

Kernel compiled with Debian distro GCC 6 but using no-pie makefile patch.

Next week and weekend will be pretty busy and this is a production machine, so 
bisection or any other time-consuming work on this is out of question for me. 
I can provide additional details in case they are easy and quick enough to 
obtain.


System information (now back on 4.8 kernel):

# phoronix-test-suite system-info

Phoronix Test Suite v5.2.1
System Information

Hardware:
Processor: Intel Core i5-2520M @ 3.20GHz (4 Cores), Motherboard: LENOVO 
42433WG, Chipset: Intel 2nd Generation Core Family DRAM, Memory: 16384MB, 
Disk: 300GB INTEL SSDSA2CW30 + 480GB Crucial_CT480M50, Graphics: Intel 2nd 
Generation Core Family IGP, Audio: Conexant CX20590, Monitor: P24T-7 LED, 
Network: Intel 82579LM Gigabit Connection + Intel Centrino Advanced-N 6205

Software:
OS: Debian unstable, Kernel: 4.8.0-1-amd64 (x86_64), Desktop: KDE Frameworks 
5, Display Server: X Server 1.18.4, Display Driver: modesetting 1.18.4, 
OpenGL: 3.3 Mesa 12.0.3, Compiler: GCC 6.2.0 20161103, File-System: btrfs, 
Screen Resolution: 3840x1080


# apt-show-versions | egrep "(^libgl1-mesa-dri|^libdrm-intel1|xserver-xorg-
core)" | grep amd64
libdrm-intel1:amd64/sid 2.4.71-1 uptodate
libgl1-mesa-dri:amd64/sid 12.0.3-3 uptodate
xserver-xorg-core:amd64/sid 2:1.18.4-2 uptodate


Excerpt of glxinfo:

Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel Open Source Technology Center (0x8086)
Device: Mesa DRI Intel(R) Sandybridge Mobile  (0x126)
Version: 12.0.3
Accelerated: yes
Video memory: 1536MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 3.3
Max compat profile version: 3.0
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.0

X.org runs with modesetting driver (default was changed in Debian Sid a while 
back).

Thanks,

Linux 4.9: Reported regressions as of Sunday, 2016-11-06

[Thorsten Leemhuis]

Hi! Here is my third regression report for Linux 4.9. It lists 17
regressions I'm aware of. 6 of them are new; 3 got fixed since
last weeks report (a fourth looks fixed as well). The console
problem ("console: don't prefer first registered [...]") got
reported to me multiple times, but the revert to finally get
this fixed is in -mm already.

As always: Are you aware of any other regressions? Then please let me
know (simply CC regressi...@leemhuis.info). And please tell me if there
is anything in the report that shouldn't be there.

Ciao, Thorsten

== Current regressions ==

Desc: thinkpad x60: BIOS limit stops working,
Repo: 16-11-05 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1264916.html
Stat: n/a 
Note: WIP

Desc: thinkpad x60:  thermal passive cooling can not prevent the system from 
overheating, when there is no BIOS limit.
Repo: 16-11-05 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1264916.html
Stat: n/a 
Note: WIP

Desc: test failures of sendfile(2) and splice(2) 
Repo: 16-11-01 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262400.html
Stat: 16-11-01 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262648.html
Note: WIP, patch available

Desc: amdgpu, topaz: powerplay initialization failed
Repo: 16-10-31 https://bugzilla.kernel.org/show_bug.cgi?id=185681 
https://bugs.freedesktop.org/show_bug.cgi?id=98357#
Stat: 16-11-04 https://bugzilla.kernel.org/show_bug.cgi?id=185681#c7
Note: WIP

Desc: mangled display since -rc1 (two systems: one with intel, one with nvidia 
gpu)
Repo: 16-10-31 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1261699.html
Stat: n/a 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262493.html
Note: root cause unknown, proper bisec needed (would be good if somebody could 
help the reporter)

Desc: "build regression: make.cross ARCH=mips fails with ""No rule to make 
target 'alchemy/devboards/'. """
Repo: 16-10-30 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1262410.html 
https://marc.info/?l=linux-kernel&m=147780880425626
Stat: n/a 
Note: nothing happened yet; BTW: Should build regressions be on this list at 
all?

Desc: tpm0: TPM self test failed & can't request region for resource
Repo: 16-10-28 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1259943.html 
https://bugzilla.kernel.org/show_bug.cgi?id=185631
Stat: 16-11-03 
https://www.mail-archive.com/tpmdd-devel@lists.sourceforge.net/msg02010.html
Note: Partly fixed by 
https://git.kernel.org/torvalds/c/befd99656c5eb765fe9d96045c4cba099fd938db , 
but it seems more fixes are needed (and available!)

Desc: boot failure of Intel Mobile Internet Devices due to a change in the PCI 
subsystem that appeared in v4.9-rc1.
Repo: 16-10-23 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1255643.html
Stat: 16-10-26 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1258579.html
Note: Poked list, as it looks like the proposed fix got forgotten

Desc: Radeon Oops on shutdown / Panic on shutdown in routine 
radeon_connector_unregister()
Repo: 16-10-19 https://bugzilla.kernel.org/show_bug.cgi?id=178421 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1261699.html
Stat: 16-10-30 https://bugzilla.kernel.org/show_bug.cgi?id=178421#c6
Note: Patch available

Desc: ""console: don't prefer first registered if DT specifies stdout-path"" 
breaks console on video outputs of various ARM boards; breaks some ppc machines 
as well
Repo: 16-10-18 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1264523.html 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253391.html 
https://www.linux-mips.org/archives/linux-mips/16-10/msg00176.html
Stat: 16-11-06 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1265059.html 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1264422.html
Note: revert discussed and also in -mm; Side note: this seems to be a 
regression that annoys quite a lot of people

Desc: unable to handle kernel NULL pointer dereference at fuse_setattr
Repo: 16-10-17 https://bugzilla.kernel.org/show_bug.cgi?id=177801
Stat: 16-10-18 https://bugzilla.kernel.org/show_bug.cgi?id=177801#c5
Note: poked Miklos, as the fix is not yet upstream afaics

Desc: Skylake gen6 suspend/resume video regression
Repo: 16-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177731 
https://bugs.freedesktop.org/show_bug.cgi?id=98517
Stat: 16-10-25 https://bugzilla.kernel.org/show_bug.cgi?id=177731#c3
Note: WIP

Desc: warning in intel_dp_aux_transfer: CPU: 0 PID: 4 at 
drivers/gpu/drm/i915/intel_dp.c:1062 intel_dp_aux_transfer+0x1ed/0x230#
Repo: 16-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177701
Stat: 16-10-27 https://bugs.freedesktop.org/show_bug.cgi?id=97344
Note: Poked Janni a week ago to give a status update, but didn't hear anything 
yet

Desc: mo

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

[Thorsten Leemhuis]

Lo! On 01.11.2016 09:18, Paul Bolle wrote:
> On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote:
>> As always: Are you aware of any other regressions? Then please let me
>> know (simply CC regressi...@leemhuis.info).
> Do build regressions count?

That's a good question.

> Because I was trying to fix an obscure build issue in arch/mips, choose
> a random configuration that should hit that issue, and promptly ran
> into
> https://lkml.kernel.org/r/<201610301405.k82kqqw0%25fengguang...@intel.com>
> The same configuration does build under v4.8, I tested that of course.

I'd say it's a practical problem that users run into and hence it's a
regression. Sure, in this case it hits only those that compile kernels
themselves; but those are users, too, and we don't want to scare them
away with things that suddenly stop working.

IOW: I'll include it in this weeks report.

Ciao, Thorsten

Linux 4.9-rc4

[Linus Torvalds]

 state when switching to kernel stack
at syscall entry

Jon Paul Maloy (1):
  tipc: fix broadcast link synchronization problem

Juergen Gross (1):
  virtio: remove config.c

Jérôme de Bretagne (1):
  Bluetooth: hci_bcm: Fix autosuspend PM for Lenovo ThinkPad 8

Kashyap Desai (1):
  scsi: megaraid_sas: Fix data integrity failure for JBOD
(passthrough) devices

Kees Cook (2):
  gcc-plugins: Export symbols needed by gcc
  latent_entropy: Fix wrong gcc code generation with 64 bit variables

Konstantin Neumoin (1):
  virtio: update balloon size in balloon "probe"

Ladi Prosek (1):
  virtio_ring: Make interrupt suppression spec compliant

Larry Finger (1):
  rtlwifi: Fix regression caused by commit d86e64768859

Lars-Peter Clausen (1):
  gpio: GPIO_GET_LINE{HANDLE,EVENT}_IOCTL: Fix file descriptor leak

Linus Lüssing (1):
  batman-adv: fix splat on disabling an interface

Linus Torvalds (2):
  sched/core: Remove pointless printout in sched_show_task()
  Linux 4.9-rc4

Liping Zhang (3):
  netfilter: xt_NFLOG: fix unexpected truncated packet
  netfilter: xt_ipcomp: add "ip[6]t_ipcomp" module alias name
  netfilter: nft_hash: add missing NFTA_HASH_OFFSET's nla_policy

Liu Bo (1):
  Btrfs: kill BUG_ON in do_relocation

Liu Ying (3):
  drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset
  drm/imx: ipuv3-plane: Skip setting u/vbo only when we don't need modeset
  drm/imx: ipuv3-plane: Access old u/vbo properly in
->atomic_check for YU12/YV12

Lucas Stach (1):
  drm/radeon: drop register readback in cayman_cp_int_cntl_setup

Maciej W. Rozycki (6):
  MIPS: ptrace: Also initialize the FP context on individual FCSR writes
  MIPS: Fix FCSR Cause bit handling for correct SIGFPE issue
  MIPS: Fix ISA I FP sigcontext access violation handling
  MIPS: Remove FIR from ISA I FP signal context
  MIPS: Fix ISA I/II FP signal context offsets
  MIPS: Correct MIPS I FP sigcontext layout

Manish Chopra (1):
  qede: Fix incorrrect usage of APIs for un-mapping DMA memory

Maor Gottlieb (1):
  net/mlx4_core: Avoid setting ports to auto when only one port
type is supported

Marcelo Ricardo Leitner (1):
  sctp: validate chunk len before actually using it

Markus Elfring (2):
  virtio_blk: Use kmalloc_array() in init_vq()
  virtio_blk: Delete an unnecessary initialisation in init_vq()

Marty Faltesek (1):
  ath10k: cache calibration data when the core is stopped

Masahiro Yamada (2):
  regmap: include  from include/linux/regmap.h
  gpio: of: fix GPIO drivers with multiple gpio_chip for a single node

Matt Redfearn (7):
  virtio: console: Unlock vqs while freeing buffers
  MIPS: KASLR: Fix handling of NULL FDT
  MIPS: generic: Fix KASLR for generic kernel.
  MIPS: Fix build of compressed image
  MIPS: traps: Fix output of show_backtrace
  MIPS: traps: Fix output of show_stacktrace
  MIPS: traps: Fix output of show_code

Mauro Carvalho Chehab (31):
  [media] af9005: don't do DMA on stack
  [media] cinergyT2-core: don't do DMA on stack
  [media] cinergyT2-core: handle error code on RC query
  [media] cinergyT2-fe: cache stats at cinergyt2_fe_read_status()
  [media] cinergyT2-fe: don't do DMA on stack
  [media] cxusb: don't do DMA on stack
  [media] dib0700: be sure that dib0700_ctrl_rd() users can do DMA
  [media] dib0700_core: don't use stack on I2C reads
  [media] dibusb: don't do DMA on stack
  [media] dibusb: handle error code on RC query
  [media] digitv: don't do DMA on stack
  [media] dtt200u-fe: don't keep waiting for lock at set_frontend()
  [media] dtt200u-fe: don't do DMA on stack
  [media] dtt200u-fe: handle errors on USB control messages
  [media] dtt200u: don't do DMA on stack
  [media] dtt200u: handle USB control message errors
  [media] dtv5100: don't do DMA on stack
  [media] gp8psk: don't do DMA on stack
  [media] gp8psk: don't go past the buffer size
  [media] nova-t-usb2: don't do DMA on stack
  [media] pctv452e: don't do DMA on stack
  [media] pctv452e: don't call BUG_ON() on non-fatal error
  [media] technisat-usb2: use DMA buffers for I2C transfers
  [media] nova-t-usb2: handle error code on RC query
  [media] dw2102: return error if su3000_power_ctrl() fails
  [media] digitv: handle error code on RC query
  [media] cpia2_usb: don't use stack for DMA
  [media] s2255drv: don't use stack for DMA
  [media] stk-webcam: don't use stack for DMA
  [media] flexcop-usb: don't use stack for DMA
  [media] radio-bcm2048: don't ignore errors

Michael Braun (1):
  mac80211: fix CMD_FRAME for AP_VLAN

Michael S. Tsirkin (2):
  virtio/vhost: add Jason to list of maintainers
  virti

Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

[Gabriel C]

Hello ,


I've tested 4.9-rcX and Linus git tree and have on this box the following 
messages :

.

Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks:
Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu_node (CPUs 
0-15): P0
Nov 05 20:26:40 zwerg kernel: (detected by 8, t=60002 jiffies, g=2426, 
c=2425, q=789)
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe

.

When I boot to console mode the system seems to work at least when I'm loggen 
in from tty1.
Switching to other tty's sometimes works sometimes not.. Starting X makes the 
box hang.. sddm starts but I
never get to the logn screen. After some minutes I have to hard reset the box..

Latest tested git kernel is 4.9.0-rc3-00429-g03daa36 , the box is a FUJITSU 
PRIMERGY TX200 S5.

config used and dmesg can be found there :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/

Best Regards

Gabriel C

[GIT PULL] KVM fixes for Linux 4.9-rc4

[Paolo Bonzini]

Linus,

The following changes since commit 07d9a380680d1c0eb51ef87ff2eab5c994949e69:

  Linux 4.9-rc2 (2016-10-23 17:10:14 -0700)

are available in the git repository at:

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

for you to fetch changes up to d9092f52d7e61dd1557f2db2400ddb430e85937e:

  kvm: x86: Check memopp before dereference (CVE-2016-8630) (2016-11-02 
21:31:53 +0100)


One NULL pointer dereference, and two fixes for regressions introduced
during the merge window.  The rest are fixes for MIPS, s390 and nested VMX.


Borislav Petkov (1):
  kvm/x86: Show WRMSR data is in hex

Ido Yariv (1):
  KVM: x86: fix wbinvd_dirty_mask use-after-free

James Hogan (3):
  KVM: MIPS: Fix lazy user ASID regenerate for SMP
  KVM: MIPS: Make ERET handle ERL before EXL
  KVM: MIPS: Precalculate MMIO load resume PC

Janosch Frank (1):
  KVM: s390: Fix STHYI buffer alignment for diag224

Jim Mattson (2):
  kvm: nVMX: Fix kernel panics induced by illegal INVEPT/INVVPID types
  kvm: nVMX: VMCLEAR an active shadow VMCS after last use

Owen Hofmann (1):
  kvm: x86: Check memopp before dereference (CVE-2016-8630)

Paolo Bonzini (4):
  KVM: fix OOPS on flush_work
  KVM: document lock orders
  Merge tag 'kvm-s390-master-4.9-2' of 
git://git.kernel.org/.../kvms390/linux into HEAD
  KVM: x86: drop TSC offsetting kvm_x86_ops to fix KVM_GET/SET_CLOCK

 Documentation/virtual/kvm/locking.txt | 12 ++-
 arch/mips/include/asm/kvm_host.h  |  7 ++--
 arch/mips/kvm/emulate.c   | 32 ++---
 arch/mips/kvm/mips.c  |  5 ++-
 arch/mips/kvm/mmu.c   |  4 ---
 arch/s390/kvm/sthyi.c |  4 +--
 arch/x86/include/asm/kvm_host.h   |  3 --
 arch/x86/kvm/emulate.c|  2 +-
 arch/x86/kvm/svm.c| 23 -
 arch/x86/kvm/vmx.c| 65 +++
 arch/x86/kvm/x86.c| 16 +
 virt/kvm/eventfd.c| 22 ++--
 virt/kvm/kvm_main.c   |  6 
 13 files changed, 95 insertions(+), 106 deletions(-)

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

[Paul Bolle]

On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote:
> As always: Are you aware of any other regressions? Then please let me
> know (simply CC regressi...@leemhuis.info).

Do build regressions count?

Because I was trying to fix an obscure build issue in arch/mips, choose
a random configuration that should hit that issue, and promptly ran
into
https://lkml.kernel.org/r/<201610301405.k82kqqw0%25fengguang...@intel.com>
The same configuration does build under v4.8, I tested that of course.

(Side note: I had to manually insert "25" after "%" to get this to
work. Should Intel fix its mail setup, or should lkml.kernel.org learn
to escape "%"?)

Thanks,


Paul Bolle

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

[Andreas Schwab]

On Okt 30 2016, Benjamin Herrenschmidt  wrote:

> On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote:
>> 
>> Desc: PPC32: fails to boot on my PowerBook G4 Aluminum; bisected to
>> commit 05fd007e4629
>> Repo: 2016-10-20 https://www.mail-archive.com/linux-kernel@vger.kerne
>> l.org/msg1253391.html
>> Stat: 2016-10-22 https://www.mail-archive.com/linux-kernel@vger.kerne
>> l.org/msg1255516.html https://www.linux-mips.org/archives/linux-mips/
>> 2016-10/msg00176.html https://lkml.org/lkml/2016/10/18/142
>> Note: Larry made a hack that works for him.
>
> This breaks framebuffer console on ppc64 I've been told as well, I
> heard...
>
> I'm at KS now, hard to get you more details, but there's something
> fishy here either with the commit or with something we do on ppc with
> fbdev that this commit breaks.

See the thread at .

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

[Linus Torvalds]

On Sun, Oct 30, 2016 at 6:20 AM, Thorsten Leemhuis
 wrote:
>
> Desc: tpm0: TPM self test failed
> Repo: 2016-10-28 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1259943.html
> Stat: 2016-10-28 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1260452.html 
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1256705.html
> Note: Fix hopefully soon heading upstream
>
> Desc: "Nokia N900 (omap3-n900) with ""VDD1: ramp_delay not set"" string in 
> printk frequently"
> Repo: 2016-10-19 https://bugzilla.kernel.org/show_bug.cgi?id=178371
> Stat: n/a https://lkml.org/lkml/2016/10/27/527
> Note: discussion on lkml ongoing

These two should hopefully be fixed as of today in current -git.

> Desc: radeon performance drop from 4.8 to 4.9-rc1 in Shadow of Mordor
> Repo: 2016-10-14 https://bugzilla.kernel.org/show_bug.cgi?id=178221 
> https://lists.freedesktop.org/archives/dri-devel/2016-October/120693.html
> Stat: 2016-10-20 
> https://lists.freedesktop.org/archives/dri-devel/2016-October/121427.html
> Note: Stuck? Poked bugzilla

I think this was fixed Friday by the merge of the PAT regression fixes
from DaveA (merge commit .bdb520845b57)

   Linus

Re: Linux 4.9: Reported regressions as of Sunday, 2016-10-30

[Benjamin Herrenschmidt]

On Sun, 2016-10-30 at 14:20 +0100, Thorsten Leemhuis wrote:
> 
> Desc: PPC32: fails to boot on my PowerBook G4 Aluminum; bisected to
> commit 05fd007e4629
> Repo: 2016-10-20 https://www.mail-archive.com/linux-kernel@vger.kerne
> l.org/msg1253391.html
> Stat: 2016-10-22 https://www.mail-archive.com/linux-kernel@vger.kerne
> l.org/msg1255516.html https://www.linux-mips.org/archives/linux-mips/
> 2016-10/msg00176.html https://lkml.org/lkml/2016/10/18/142
> Note: Larry made a hack that works for him.

This breaks framebuffer console on ppc64 I've been told as well, I
heard...

I'm at KS now, hard to get you more details, but there's something
fishy here either with the commit or with something we do on ppc with
fbdev that this commit breaks.

Cheers,
Ben.

Linux 4.9: Reported regressions as of Sunday, 2016-10-30

[Thorsten Leemhuis]

Hi! Here is my second regression report for Linux 4.9. It lists 14
regressions I'm aware of. 4 of them are new; 3 got fixed since last weeks 
report.

As always: Are you aware of any other regressions? Then please let me
know (simply CC regressi...@leemhuis.info). And please tell me if there
is anything in the report that shouldn't be there.

Ciao, Thorsten

== Current regressions ==

Desc: tpm0: TPM self test failed
Repo: 2016-10-28 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1259943.html
Stat: 2016-10-28 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1260452.html 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1256705.html 
Note: Fix hopefully soon heading upstream

Desc: Radeon Oops on shutdown
Repo: 2016-10-19 https://bugzilla.kernel.org/show_bug.cgi?id=178421
Stat: 2016-10-30 https://bugzilla.kernel.org/show_bug.cgi?id=178421#c6
Note: WIP

Desc: module loadling broken due to kbuild changes
Repo: 2016-10-15 http://www.gossamer-threads.com/lists/linux/kernel/2544734
Stat: 2016-10-27 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1259418.html
Note: Fix available, waiting for Michal to get back from vacation; wondering if 
those will fix https://bugzilla.kernel.org/show_bug.cgi?id=185581 and 
https://lkml.org/lkml/2016/10/27/471 and 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1250105.html as 
well

Desc: pci: artpec-6: imprecise external abort
Repo: 2016-10-14 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1249646.html
Stat: 2016-10-14 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1249922.html
Note: Patch available

Desc: PPC32: fails to boot on my PowerBook G4 Aluminum; bisected to commit 
05fd007e4629
Repo: 2016-10-20 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253391.html
Stat: 2016-10-22 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1255516.html 
https://www.linux-mips.org/archives/linux-mips/2016-10/msg00176.html 
https://lkml.org/lkml/2016/10/18/142
Note: Larry made a hack that works for him.

Desc: "Nokia N900 (omap3-n900) with ""VDD1: ramp_delay not set"" string in 
printk frequently"
Repo: 2016-10-19 https://bugzilla.kernel.org/show_bug.cgi?id=178371
Stat: n/a https://lkml.org/lkml/2016/10/27/527
Note: discussion on lkml ongoing

Desc: radeon performance drop from 4.8 to 4.9-rc1 in Shadow of Mordor
Repo: 2016-10-14 https://bugzilla.kernel.org/show_bug.cgi?id=178221 
https://lists.freedesktop.org/archives/dri-devel/2016-October/120693.html
Stat: 2016-10-20 
https://lists.freedesktop.org/archives/dri-devel/2016-October/121427.html
Note: Stuck? Poked bugzilla

Desc: unable to handle kernel NULL pointer dereference at fuse_setattr
Repo: 2016-10-17 https://bugzilla.kernel.org/show_bug.cgi?id=177801
Stat: 2016-10-18 https://bugzilla.kernel.org/show_bug.cgi?id=177801#c5
Note: Fix heading upstream

Desc: Skylake gen6 suspend/resume video regression
Repo: 2016-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177731
Stat: 2016-10-25 https://bugzilla.kernel.org/show_bug.cgi?id=177731#c3
Note: WIP

Desc: warning in intel_dp_aux_transfer: CPU: 0 PID: 4 at 
drivers/gpu/drm/i915/intel_dp.c:1062 intel_dp_aux_transfer+0x1ed/0x230#
Repo: 2016-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177701
Stat: 2016-10-27 https://bugs.freedesktop.org/show_bug.cgi?id=97344
Note: Poked Janni to give a statement

Desc: """Failed to find cpu0 device node"" in dmesg"
Repo: 2016-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177681 
https://bugzilla.kernel.org/show_bug.cgi?id=180031
Stat: 2016-10-28 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1260133.html
Note: Patches afaics in the work

Desc: boot failure of Intel Mobile Internet Devices due to a change in the PCI 
subsystem that appeared in v4.9-rc1.
Repo: 2016-10-23 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1255643.html
Stat: 2016-10-26 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1258579.html
Note: Fix proposed

Desc: 4.9-rc1 boot regression, ambiguous bisect result
Repo: 2016-10-19 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253369.html
Stat: 2016-10-21 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1255296.html
Note: Poked list, as this looks stuck or was is discussed (or even fixed) 
somewhere else


== Stalled, waiting for feedback from reporter ==

Desc: can't boot with root fs on md raid 0; mdadm: no devices listed in conf 
file were found. 
Repo: 2016-10-17 https://bugzilla.kernel.org/show_bug.cgi?id=178211
Stat: 2016-10-18 https://bugzilla.kernel.org/show_bug.cgi?id=178211#c1
Note: Root cause unknown; might be a controller driver issue


== Going to be removed from the list ==

Desc: some gpio drivers broken by commit 762c2e46
Repo: 2016-10-18 https://www.spinics.net/lists/linux-gpio/msg17283.html
Stat: 2016-10-21 
https://www.mail-archive.com/linux-k

Linux 4.9-rc3

[Linus Torvalds]

U device removal with a 'pmu_bus_running'
check, to fix CONFIG_DEBUG_TEST_DRIVER_REMOVE=y kernel panic
  perf/powerpc: Don't call perf_event_disable() from atomic context

Jiri Slaby (1):
  tty: vt, fix bogus division in csi_J

Jisheng Zhang (1):
  MAINTAINERS: add myself as Marvell berlin SoC maintainer

Jitendra Bhivare (2):
  scsi: libiscsi: Fix locking in __iscsi_conn_send_pdu
  scsi: be2iscsi: Replace _bh with _irqsave/irqrestore

Joe Perches (1):
  mm: page_alloc: use KERN_CONT where appropriate

Johan Hovold (2):
  USB: serial: cp210x: fix tiocmget error handling
  USB: serial: fix potential NULL-dereference at probe

Johannes Weiner (1):
  mm: memcontrol: do not recurse in direct reclaim

John W. Linville (1):
  nbd: fix incorrect unlock of nbd->sock_lock in sock_shutdown

John Youn (3):
  Revert "usb: dwc2: gadget: change variable name to more meaningful"
  Revert "usb: dwc2: gadget: fix TX FIFO size and address initialization"
  Revert "Documentation: devicetree: dwc2: Deprecate g-tx-fifo-size"

Jon Hunter (1):
  PM / suspend: Fix missing KERN_CONT for suspend message

Joonsoo Kim (1):
  mm/slab: fix kmemcg cache creation delayed issue

Jorgen Hansen (1):
  VMCI: Doorbell create and destroy fixes

Josh Poimboeuf (2):
  x86/unwind: Fix empty stack dereference in guess unwinder
  objtool: Fix rare switch jump table pattern detection

Juergen Gross (1):
  xenbus: advertise control feature flags

Kees Cook (1):
  latent_entropy: raise CONFIG_FRAME_WARN by default

Lars-Peter Clausen (8):
  gpio: GPIO_GET_CHIPINFO_IOCTL: Fix line offset validation
  gpio: GPIO_GET_CHIPINFO_IOCTL: Fix information leak
  gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset
  gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak
  gpio: GPIO_GET_LINEEVENT_IOCTL: Validate line offset
  gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak
  gpio: GPIO_GET_LINEHANDLE_IOCTL: Reject invalid line flags
  gpio: GPIO_GET_LINEEVENT_IOCTL: Reject invalid line and event flags

Laura Abbott (1):
  driver core: Make Kconfig text for DEBUG_TEST_DRIVER_REMOVE stronger

Leon Yu (1):
  proc: fix NULL dereference when reading /proc//auxv

Linus Torvalds (5):
  proc: don't use FOLL_FORCE for reading cmdline and environment
  mm: remove per-zone hashtable of bitlock waitqueues
  mm: remove unused variable in memory hotplug
  Allow KASAN and HOTPLUG_MEMORY to co-exist when doing build testing
  Linux 4.9-rc3

Linus Walleij (2):
  ARM: dts: fix the SD card on the Snowball
  bus: qcom-ebi2: depend on ARCH_QCOM or COMPILE_TEST

Liu Gang (1):
  gpio: mpc8xxx: Correct irq handler function

Long Li (1):
  hv: do not lose pending heartbeat vmbus packets

Lorenzo Stoakes (1):
  mm: unexport __get_user_pages()

Lukasz Odzioba (1):
  perf/x86/intel/cstate: Add C-state residency events for Knights Landing

Lv Zheng (3):
  ACPICA: Dispatcher: Fix order issue of method termination
  ACPICA: Dispatcher: Fix an unbalanced lock exit path in
acpi_ds_auto_serialize_method()
  ACPICA: Dispatcher: Fix interpreter locking around
acpi_ev_initialize_region()

Marcel Hasler (1):
  ALSA: usb-audio: Add quirk for Syntek STK1160

Marcin Wojtas (1):
  arm64: dts: marvell: fix clocksource for CP110 master SPI0

Mark Rutland (1):
  h8300: fix syscall restarting

Martin Kepplinger (1):
  CREDITS: update credit information for Martin Kepplinger

Martyn Welch (1):
  vme: vme_get_size potentially returning incorrect value on failure

Masahiro Yamada (12):
  clk: uniphier: add system clock support for sLD3 SoC
  clk: uniphier: fix type of variable passed to regmap_read()
  clk: uniphier: fix memory overrun bug
  clk: uniphier: rename MIO clock to SD clock for Pro5, PXs2, LD20 SoCs
  ARM: uniphier: select ARCH_HAS_RESET_CONTROLLER
  arm64: uniphier: select ARCH_HAS_RESET_CONTROLLER
  reset: uniphier: rename MIO reset to SD reset for Pro5, PXs2, LD20 SoCs
  ARM: dts: uniphier: change MIO node to SD control node
  arm64: dts: uniphier: change MIO node to SD control node
  usb: ehci-platform: increase EHCI_MAX_RSTS to 4
  serial: 8250_uniphier: fix clearing divisor latch access bit
  kconfig.h: remove config_enabled() macro

Mathias Nyman (3):
  xhci: add restart quirk for Intel Wildcatpoint PCH
  xhci: workaround for hosts missing CAS bit
  xhci: use default USB_RESUME_TIMEOUT when resuming ports.

Michael Ellerman (1):
  KVM: PPC: Book3S HV: Fix build error when SMP=n

Michal Nazarewicz (2):
  usb: gadget: f_fs: edit epfile->ep under lock
  usb: gadget: f_fs: stop sleeping in ffs_func_eps_disable

Mika Westerberg (1):
  iio: adc: ti-adc081c: Select IIO_TRIGGERED_BUFFER to prevent build errors

Mike Snitzer (1):
  dm rq: clear kworker_ta

Re: [GIT PULL] tpmdd critical fix for Linux 4.9

[Jarkko Sakkinen]

On Thu, Oct 06, 2016 at 11:35:56AM +0300, Jarkko Sakkinen wrote:
> Hi James,
> 
> One critical fix that breaks tpm_tis init so I decided to do an
> immediate pull request. Thanks.

Can you pull this?

/Jarkko

> /Jarkko
> 
> The following changes since commit 1306d8e1c09fdc8ecb9ef235e2116352f810f9c5:
> 
>   Merge tag 'tpmdd-next-20160927' of 
> git://git.infradead.org/users/jjs/linux-tpmdd into ra-next (2016-09-27 
> 19:21:37 +1000)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20161005
> 
> for you to fetch changes up to 65da72b7ddcdd8990e4783d09c7e86d90ccb4121:
> 
>   tpm: remove invalid min length check from tpm_do_selftest() (2016-10-05 
> 18:21:58 +0300)
> 
> --------
> tpmdd critical fix for Linux 4.9
> 
> 
> Jarkko Sakkinen (1):
>   tpm: remove invalid min length check from tpm_do_selftest()
> 
>  drivers/char/tpm/tpm-interface.c | 3 ---
>  1 file changed, 3 deletions(-)

Linux 4.9-rc2

[Linus Torvalds]

own_write()

Junjie Mao (1):
  btrfs: assign error values to the correct bio structs

Keith Busch (3):
  nvme: Stop probing a removed device
  nvme: Delete created IO queues on reset
  nvme: don't schedule multiple resets

Linus Torvalds (3):
  mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
  printk: suppress empty continuation lines
  Linux 4.9-rc2

Longpeng(Mike) (1):
  x86: Remove duplicate rtit status MSR macro

Lorenzo Pieralisi (1):
  arm64: kernel: numa: fix ACPI boot cpu numa node mapping

Lorenzo Stoakes (10):
  mm: remove write/force parameters from __get_user_pages_locked()
  mm: remove write/force parameters from __get_user_pages_unlocked()
  mm: replace get_user_pages_unlocked() write/force parameters
with gup_flags
  mm: replace get_user_pages_locked() write/force parameters with gup_flags
  mm: replace get_vaddr_frames() write/force parameters with gup_flags
  mm: replace get_user_pages() write/force parameters with gup_flags
  mm: replace get_user_pages_remote() write/force parameters with gup_flags
  mm: replace __access_remote_vm() write parameter with gup_flags
  mm: replace access_remote_vm() write parameter with gup_flags
  mm: replace access_process_vm() write parameter with gup_flags

Lucas Stach (2):
  drm/etnaviv: ensure write caches are flushed at end of user cmdstream
  drm/etnaviv: block 64K of address space behind each cmdstream

Marc Zyngier (5):
  irqchip/gic-v3-its: Fix 64bit GIC{R,ITS}_TYPER accesses
  PCI: layerscape: Fix drvdata usage before assignment
  arm64: kernel: Init MDCR_EL2 even in the absence of a PMU
  irqchip/gic: Add missing \n to CPU IF adjustment message
  arm/arm64: KVM: Map the BSS at HYP

Marek Olšák (1):
  drm/radeon: allow TA_CS_BC_BASE_ADDR on SI

Mark Rutland (2):
  arm64: fix show_regs fallout from KERN_CONT changes
  arm64: remove pr_cont abuse from mem_init

Markus Elfring (3):
  drm/vmwgfx: Use kmalloc_array() in vmw_surface_define_ioctl()
  drm/vmwgfx: Use memdup_user() rather than duplicating its implementation
  drm/vmwgfx: Adjust checks for null pointers in 13 functions

Michael Ellerman (1):
  powerpc/mm: Drop dump_numa_memory_topology()

Mika Westerberg (2):
  pinctrl: intel: Only restore pins that are used by the driver
  watchdog: wdat_wdt: Ping the watchdog on resume

Ming Lei (2):
  scsi: Fix use-after-free
  scsi: Remove one useless stack variable

Namhyung Kim (1):
  perf top: Fix refreshing hierarchy entries on TUI

Nicholas Bellinger (3):
  target: Re-add missing SCF_ACK_KREF assignment in v4.1.y
  target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET
DEVICE NOT REACHABLE
  Revert "target: Fix residual overflow handling in
target_complete_cmd_with_length"

Nicolai Hähnle (1):
  drm/amdgpu: initialize the context reset_counter in amdgpu_ctx_init

Nikolay Borisov (1):
  ceph: fix error handling in ceph_read_iter

Noam Camus (1):
  irqchip/eznps: Acknowledge NPS_IPI before calling the handler

Peter Zijlstra (1):
  locking, fs/locks: Add missing file_sem locks

Piotr Luc (5):
  x86/cpu/intel: Add Knights Mill to Intel family
  perf/x86/intel: Add Knights Mill CPUID
  perf/x86/intel/rapl: Add Knights Mill CPUID
  perf/x86/intel/uncore: Add Knights Mill CPUID
  x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features

Renat Valiullin (1):
  x86/vmware: Skip timer_irq_works() check on VMware

Rex Zhu (6):
  drm/amdgpu: change vblank_time's calculation method to reduce
computational error.
  drm/amd/powerplay: fix static checker warnings in iceland_smc.c
  drm/amd/powerplay: fix static checker warnings in smu7_hwmgr.c
  drm/amd/powerplay: fix static checker warnings in smu7_hwmgr.c
  drm/amd/powerplay: notify smu no display by default.
  drm/amd/powerplay: fix bug stop dpm can't work on Vi.

Rich Felker (7):
  sh: support CPU_J2 when compiler lacks -mj2
  irqchip/jcore: Fix lost per-cpu interrupts
  sh: add Kconfig option for J-Core SoC core drivers
  sh: add earlycon support to j2_defconfig
  irqchip/jcore: Don't show Kconfig menu item for driver
  of: Add J-Core timer bindings
  clocksource: Add J-Core timer/clocksource driver

Richard Weinberger (3):
  ubifs: Rename ubifs_rename2
  ubifs: Fix xattr_names length in exit paths
  ubifs: Abort readdir upon error

Russell King (1):
  drm/armada: fix clock counts

Sergey Senozhatsky (1):
  cpufreq: fix overflow in cpufreq_table_find_index_dl()

Shawn Lin (3):
  mmc: core: switch to 1V8 or 1V2 for hs400es mode
  mmc: core: changes frequency to hs_max_dtr when selecting hs400es
  mmc: sdhci-of-arasan: add sdhci_arasan_voltage_switch for arasan, 5.1

Stefan Agner (4):
  drm/fsl-dcu: enable TCON bypass mode by default
  drm/fsl-dcu: do not transfer regist

Linux 4.9: Reported regressions as of Sunday, 2016-10-23

[Thorsten Leemhuis]

Hi! Here is my first regression report for Linux 4.9. It lists 14
regressions I'm aware of. 
 
As always: Are you aware of any other regressions? Then please let me
know (simply CC regressi...@leemhuis.info). And please tell me if there
is anything in the report that shouldn't be there.

Ciao, Thorsten

P.S.: I ran out of time today (I really need to automate some things, 
but I do not find time for it…; and some of the regression tracking work 
simply can not be automated :/) and could not make it completely 
through my backlog. That's why I likely missed lots of regressions 
that were reported during the merge window and remain unfixed as of now 
:-/ Let me know about those, please.

== Current regressions ==

Desc: PPC32: fails to boot on my PowerBook G4 Aluminum; bisected to commit 
05fd007e4629
Repo: 2016-10-20 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253391.html
Stat: 2016-10-22 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1255516.html
Note: no response from responsible developers yet

Desc: "Nokia N900 (omap3-n900) with ""VDD1: ramp_delay not set"" string in 
printk frequently"
Repo: 2016-10-19 https://bugzilla.kernel.org/show_bug.cgi?id=178371
Stat: n/a 
Note: told reporter whom to contact

Desc: radeon performance drop from 4.8 to 4.9-rc1 in Shadow of Mordor
Repo: 2016-10-14 https://bugzilla.kernel.org/show_bug.cgi?id=178221 
https://lists.freedesktop.org/archives/dri-devel/2016-October/120693.html
Stat: 2016-10-20 
https://lists.freedesktop.org/archives/dri-devel/2016-October/121427.html
Note: WIP

Desc: can't boot with root fs on md raid 0; mdadm: no devices listed in conf 
file were found. 
Repo: 2016-10-17 https://bugzilla.kernel.org/show_bug.cgi?id=178211
Stat: 2016-10-18 https://bugzilla.kernel.org/show_bug.cgi?id=178211#c1
Note: Root cause unknown; might be a controller driver issue

Desc: unable to handle kernel NULL pointer dereference at fuse_setattr
Repo: 2016-10-17 https://bugzilla.kernel.org/show_bug.cgi?id=177801
Stat: 2016-10-18 https://bugzilla.kernel.org/show_bug.cgi?id=177801#c5
Note: Fix heading upstream

Desc: Skylake gen6 suspend/resume video regression
Repo: 2016-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177731
Stat: n/a 
Note: 

Desc: warning in intel_dp_aux_transfer: CPU: 0 PID: 4 at 
drivers/gpu/drm/i915/intel_dp.c:1062 intel_dp_aux_transfer+0x1ed/0x230#
Repo: 2016-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177701
Stat: n/a 
Note: 

Desc: """Failed to find cpu0 device node"" in dmesg"
Repo: 2016-10-16 https://bugzilla.kernel.org/show_bug.cgi?id=177681 
https://bugzilla.kernel.org/show_bug.cgi?id=180031
Stat: n/a 
Note: 

Desc: boot failure of Intel Mobile Internet Devices due to a change in the PCI 
subsystem that appeared in v4.9-rc1.
Repo: 2016-10-23 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1255643.html
Stat: n/a 
Note: Fix proposed

Desc: "Regression with 0b9e2988ab22 (""ahci: use pci_alloc_irq_vectors"")"
Repo: 2016-10-21 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1254825.html
Stat: 2016-10-21 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1254882.html
Note: WIP

Desc: 761ed4a94582 tty: serial_core: convert uart_close to use tty_port_close
Repo: 2016-10-21 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1254753.html
Stat: 2016-10-21 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1254987.html
Note: WIP

Desc: [selinux/audit/netlink, regression?] Warning at kernel/softirq.c:161
Repo: 2016-10-20 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1254148.html
Stat: 2016-10-20 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1254151.html 
https://patchwork.ozlabs.org/patch/684753/
Note: WIP

Desc: some gpio drivers broken by commit 762c2e46
Repo: 2016-10-18 https://www.spinics.net/lists/linux-gpio/msg17283.html
Stat: 2016-10-21 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253906.html
Note: WIP

Desc: 4.9-rc1 boot regression, ambiguous bisect result
Repo: 2016-10-19 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1253369.html
Stat: 2016-10-21 
https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1255296.html
Note: WIP

Re: linux-4.9-rc1/drivers/staging/lustre/lustre/osc/osc_request.c:973: always false test ?

[gre...@linuxfoundation.org]

On Mon, Oct 17, 2016 at 07:33:33AM +, David Binderman wrote:
> Hello there,
> 
> 
> 
> linux-4.9-rc1/drivers/staging/lustre/lustre/osc/osc_request.c:973]: (style) 
> Checking if unsigned variable 'cli.cl_avail_grant' is less than zero.
> 
> 
> 
> Source code is
> 
> 
> 
>    if (cli->cl_avail_grant < 0) {
> 
> 
> 
> Suggest code rework.

Great!  Please send a patch.

thanks,

greg k-h

Re: linux-4.9-rc1/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1561: poor error checking ?

[Luca Coelho]

Hi David,
On Mon, 2016-10-17 at 07:40 +, David Binderman wrote:
> Hello there,
> 
> linux-4.9-rc1/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c:1561]: (style) 
> Checking if unsigned variable 'len' is less than zero.
> 
> Source code is
> 
> len = min((size_t)le32_to_cpu(rsp->len) << 2,
>   iwl_rx_packet_payload_len(hcmd.resp_pkt) - sizeof(*rsp));
> len = min(len - delta, count);
> if (len < 0) {
> ret = -EFAULT;
> goto out;
> }
> 
> Suggest improve error checking.

Thanks for reporting! A fix for this is already queued in our internal
tree and will be sent upstream soon.

--
Cheers,
Luca.

linux-next: stats (Was: Linux 4.9-rc1)

[Stephen Rothwell]

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20161004 was the first linux-next after
the merge window opened.)

Commits in v4.9-rc1 (relative to v4.8):14308
Commits in next-20161004:  13539
Commits with the same SHA1:12716
Commits with the same patch_id:  485 (1)
Commits with the same subject line:   33 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20161004: 13234 92%

Some breakdown of the list of extra commits (relative to next-20161004)
in -rc1:

Top ten first word of commit summary:

110 pci
 96 ib
 75 powerpc
 69 xfs
 57 media
 52 drm
 37 net
 28 perf
 25 mips
 22 scsi

Top ten authors:

104 bhelg...@google.com
 73 darrick.w...@oracle.com
 42 npig...@gmail.com
 40 trond.mykleb...@primarydata.com
 28 ouli...@huawei.com
 24 bhaktipriy...@gmail.com
 22 chuck.le...@oracle.com
 21 paul.bur...@imgtec.com
 21 cyril...@gmail.com
 19 boris.brezil...@free-electrons.com

Top ten commiters:

127 dledf...@redhat.com
113 bhelg...@google.com
100 anna.schuma...@netapp.com
 94 m...@ellerman.id.au
 92 da...@davemloft.net
 63 darrick.w...@oracle.com
 57 mche...@kernel.org
 40 torva...@linux-foundation.org
 35 a...@redhat.com
 28 r...@linux-mips.org

There are also 305 commits in next-20161004 that didn't make it into
v4.9-rc1.

Top ten first word of commit summary:

 37 drm
 28 coresight
 19 arm
 12 powerpc
 11 arm64
 11 arm-soc
  9 keys
  8 mm
  8 ima
  6 bf609

Top ten authors:

 17 bauer...@linux.vnet.ibm.com
 17 a...@linux-foundation.org
 14 paul...@linux.vnet.ibm.com
 14 jani.nik...@intel.com
 13 a...@arndb.de
 12 mathieu.poir...@linaro.org
 11 dhowe...@redhat.com
  8 t...@kernel.org
  8 suzuki.poul...@arm.com
  8 jav...@osg.samsung.com

Some of Andrew's patches are fixes for other patches in his tree (and
have been merged into those).

Top ten commiters:

 71 s...@canb.auug.org.au
 31 mathieu.poir...@linaro.org
 22 paul...@linux.vnet.ibm.com
 17 jani.nik...@intel.com
 16 steven@ubuntu-virtualbox.(none)
 16 a...@arndb.de
 14 he...@sntech.de
 11 dhowe...@redhat.com
  8 t...@kernel.org
  6 rodrigo.v...@intel.com

Those commits by me are from the quilt series (mainly Andrew's mmotm
tree).

-- 
Cheers,
Stephen Rothwell

Linux 4.9-rc1

[Linus Torvalds]

I usually do the releases on a Sunday afternoon, but occasionally cut
the merge window short by a day just to keep people on their toes, and
make sure people learn not to send in last-minute pull requests. No
gaming the merge window to the last day. This is one such release.

To be fair, the reason I did it a day early this time around is less
to stop people from trying to time their pull requests, and mostly
because this has been a pretty big merge window, and not hugely
enjoyable. I ended up stopping doing pulls twice during the merge
window just because I was chasing down some random problem. That tends
to turn my busy merge window time from "busy" to "somewhat stressful".

But hey, it's all good now, and while 4.9 looks to be a big release
and we had a couple of hiccups, on the whole things look normal. The
big new thing is the greybus addition, which Greg swears is actually
getting used. But the bulk of the changes by far is actually a lot of
small details under the hood, as usual.

My own favorite "small detail under the hood" happens to be Andy
Lutomirski's new virtually mapped kernel stack allocations. They make
it easier to find and recover from stack overflows, but the effort
also cleaned up some code, and added a kernel stack mapping cache to
avoid any performance downsides. Al has also been working on some vfs
and uaccess cleanups (particularly a goo splice model cleanup) that I
follow. But realistically, what _I_ consider cool small details is
just my own personal thing, there's things all over.

The virtual stack mapping also happens to mean that people who try to
do DMA from temporary buffers on the stack ("Don't do it!") now really
need to change their evil ways. So there is some fallout from this,
and I expect a couple of drivers to need minor fixes. But it's all for
a good cause, really (and it isn't all that common, because doing DMA
from the stack really has never been a good idea, and is generally not
even workable in most situations).

But there really is a lot of other things going on, and the shortlog
that I do for other releases is much too big during rc1. So as usual,
I'm appending my "mergelog" instead, which gives a very high-level
view of what I merged and from whom. And as usual, I want to point out
that the person I merge from is not necessarily the person who did the
work: we had 1500 people involved in this release, only the top-level
maintainers get credited in my mergelog.

Go forth and test,

 Linus

---

Al Viro (7):
VFS splice updates
misc vfs updates
splice fixups
vfs xattr updates
more vfs updates
uaccess.h prepwork
more misc uaccess and vfs updates

Alex Williamson (1):
VFIO updates

Alexandre Belloni (1):
RTC updates

Andrew Morton (2):
updates
more updates

Anna Schumaker (1):
NFS client updates

Arnd Bergmann (8):
ARM SoC cleanups
ARM SoC platform updates
ARM SoC defconfig updates
ARM SoC 64-bit updates
ARM SoC driver updates
ARM DT updates
ARM 64-bit DT updates
ARM SoC late DT updates

Bjorn Andersson (2):
remoteproc updates
rpmsg updates

Bjorn Helgaas (1):
PCI updates

Bob Peterson (1):
gfs2 updates

Borislav Petkov (1):
EDAC updates

Brian Norris (1):
MTD updates

Bruce Fields (1):
nfsd updates

Chris Mason (2):
btrfs updates
btrfs fixes

Dan Williams (1):
libnvdimm updates

Darren Hart (1):
x86 platform drivers updates

Dave Airlie (1):
drm updates

Dave Chinner (2):
xfs and iomap updates
XFS support for shared data extents

David Kleikamp (1):
jfs updates

David Miller (5):
networking updates
sparc updates
networking fixups
networking fixes
networking fixes

David Teigland (1):
dlm fix

David Vrabel (1):
xen updates

Dmitry Torokhov (2):
input subsystem updates
some more input subsystem updates

Doug Ledford (5):
hdi1 rdma driver updates
more rdma updates
main rdma updates
more rdma updates
rdma qedr RoCE driver

Eric Biederman (1):
namespace updates

Geert Uytterhoeven (1):
m68k updates

Greg KH (5):
char/misc driver updates
driver core updates
tty and serial updates
usb/phy/extcon updates
staging and IIO updates

Greg Ungerer (1):
m68knommu updates

Guenter Roeck (1):
hwmon updates

Hans-Christian Noren Egtvedt (1):
avr32 update

Helge Deller (2):
parisc updates
parisc fixes

Herbert Xu (1):
crypto updates

Ilya Dryomov (1):
Ceph updates

Ingo Molnar (14):
RCU updates
core SMP updates
EFI updates
locking updates
perf updates
RAS updates
scheduler changes
x86 apic updates
low-level x86 updates
x86 boot updates
x86 cleanups
x86 platform changes
x86 timer updates
x86 vdso updates

Jacek Anaszewski (1):
LED driver updates

Jaegeuk Kim (1):
f2fs updates

James Bottomley (2):
SCSI updates
more SCSI updates

James Hogan (1):
   

Re: [GIT PULL] Please pull NFS client changes for Linux 4.9

[Anna Schumaker]

On 10/14/2016 12:24 AM, Linus Torvalds wrote:
> On Thu, Oct 13, 2016 at 1:21 PM, Anna Schumaker
>  wrote:
>>
>>   git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.9-1
> 
> Please keep the summary of changes in the email too. I can see it in
> the tag, and it will show up when I do a pull that way, but I'd
> _really_ like to see it in the email too as I prepare to pull..
> 
> Pull requests shouldn't be like Kinder eggs or like Christmas. No
> surprises, please.
> 
> (I'll pull it after my current build finishes, but for next time,
> please double-check your scripts or workflows).

Okay, I'll fix that up for next time.  Sorry about the extra hassle!

Anna

> 
>   Linus
> 

Re: [GIT PULL] Please pull NFS client changes for Linux 4.9

[Linus Torvalds]

On Thu, Oct 13, 2016 at 1:21 PM, Anna Schumaker
 wrote:
>
>   git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.9-1

Please keep the summary of changes in the email too. I can see it in
the tag, and it will show up when I do a pull that way, but I'd
_really_ like to see it in the email too as I prepare to pull..

Pull requests shouldn't be like Kinder eggs or like Christmas. No
surprises, please.

(I'll pull it after my current build finishes, but for next time,
please double-check your scripts or workflows).

  Linus

[GIT PULL] Please pull NFS client changes for Linux 4.9

[Anna Schumaker]

Hi Linus,

The following changes since commit 3be7988674ab33565700a37b210f502563d932e6:

  Linux 4.8-rc7 (2016-09-18 17:27:41 -0700)

are available in the git repository at:

  git://git.linux-nfs.org/projects/anna/linux-nfs.git tags/nfs-for-4.9-1

for you to fetch changes up to 3f807e5ae5597bd65a6fff684083e8eaa21f3fa7:

  NFSv4.2: Fix a reference leak in nfs42_proc_layoutstats_generic (2016-10-04 
16:30:54 -0400)

The patch "nfs: add a new NFS4_OPEN_RESULT_MAY_NOTIFY_LOCK constant" is also 
included in Bruce's NFSD pull request since it modifies shared code between the 
client and the server.

Thanks,
Anna


Amitoj Kaur Chawla (1):
  sunrpc: Remove unnecessary variable

Andy Adamson (12):
  NFS setup async exchange_id
  NFS refactor nfs4_match_clientids
  NFS refactor nfs4_check_serverowner_major_id
  NFS detect session trunking
  SUNRPC remove rpc_task_release_client from rpc_task_set_client
  SUNRPC rpc_clnt_xprt_switch_put
  SUNRPC rpc_clnt_xprt_switch_add_xprt
  SUNRPC search xprt switch for sockaddr
  SUNRPC: rpc_clnt_add_xprt setup function for NFS layer
  NFS add xprt switch addrs test to match client
  NFS test session trunking with exchange id
  NFS pnfs data server multipath session trunking

Chao Yu (1):
  nfs: cover ->migratepage with CONFIG_MIGRATION

Chuck Lever (22):
  xprtrdma: Eliminate INLINE_THRESHOLD macros
  SUNRPC: Refactor rpc_xdr_buf_init()
  SUNRPC: Generalize the RPC buffer allocation API
  SUNRPC: Generalize the RPC buffer release API
  SUNRPC: Separate buffer pointers for RPC Call and Reply messages
  SUNRPC: Add a transport-specific private field in rpc_rqst
  xprtrdma: Initialize separate RPC call and reply buffers
  xprtrdma: Use smaller buffers for RPC-over-RDMA headers
  xprtrdma: Replace DMA_BIDIRECTIONAL
  xprtrdma: Delay DMA mapping Send and Receive buffers
  xprtrdma: Eliminate "ia" argument in rpcrdma_{alloc, free}_regbuf
  xprtrdma: Simplify rpcrdma_ep_post_recv()
  xprtrdma: Move send_wr to struct rpcrdma_req
  xprtrdma: Move recv_wr to struct rpcrdma_rep
  rpcrdma: RDMA/CM private message data structure
  xprtrdma: Client-side support for rpcrdma_connect_private
  xprtrdma: Basic support for Remote Invalidation
  xprtrdma: Use gathered Send for large inline messages
  xprtrdma: Support larger inline thresholds
  xprtrmda: Report address of frmr, not mw
  xprtrdma: Rename rpcrdma_receive_wc()
  xprtrdma: Eliminate rpcrdma_receive_worker()

Daniel Wagner (3):
  NFS: direct: use complete() instead of complete_all()
  NFS: cache_lib: use complete() instead of complete_all()
  xprtrdma: use complete() instead complete_all()

David Vrabel (1):
  sunrpc: fix write space race causing stalls

Deepa Dinamani (1):
  fs: nfs: Make nfs boot time y2038 safe

Frank Sorenson (5):
  sunrpc: add hash_cred() function to rpc_authops struct
  sunrpc: add generic_auth hash_cred() function
  sunrpc: add auth_unix hash_cred() function
  sunrpc: add RPCSEC_GSS hash_cred() function
  sunrpc: replace generic auth_cred hash with auth-specific function

Jeff Layton (12):
  pnfs: track multiple layout types in fsinfo structure
  pnfs: add a new mechanism to select a layout driver according to an 
ordered list
  nfs: the length argument to read_buf should be unsigned
  nfs: eliminate pointless and confusing do_vfs_lock wrappers
  nfs: use safe, interruptible sleeps when waiting to retry LOCK
  nfs: add a new NFS4_OPEN_RESULT_MAY_NOTIFY_LOCK constant
  nfs: track whether server sets MAY_NOTIFY_LOCK flag
  nfs: add handling for CB_NOTIFY_LOCK in client
  nfs: move nfs4_set_lock_state call into caller
  nfs: move nfs4 lock retry attempt loop to a separate function
  nfs: allow blocking locks to be awoken by lock callbacks
  NFSv4.2: Fix a reference leak in nfs42_proc_layoutstats_generic

Ke Wang (1):
  sunrpc: queue work on system_power_efficient_wq

Olga Kornievskaia (1):
  Retry operation on EREMOTEIO on an interrupted slot

Trond Myklebust (40):
  NFSv4.x: Set up struct svc_serv_ops for the callback channel
  SUNRPC: Initialise struct svc_serv backchannel fields during 
__svc_create()
  NFSv4.x: Fix up the global tracking of the callback server
  NFSv4.x: Switch to using svc_set_num_threads() to manage the callback 
threads
  NFSv4.x: Add kernel parameter to control the callback server
  NFS: nfs_prime_dcache must validate the filename
  SUNRPC: Fix corruption of xdr->nwords in xdr_copy_to_scratch
  SUNRPC: Fix setting of buffer length in xdr_set_next_buffer()
  NFSv4.1: Don't deadlock the state manager on the SEQUENCE status flags
  NFS: Fix inode corruption in nfs_prime_dcache()
  NFSv4: Don't report revoked delegations as valid in nfs_have_delegation(

[GIT PULL] tpmdd critical fix for Linux 4.9

[Jarkko Sakkinen]

Hi James,

One critical fix that breaks tpm_tis init so I decided to do an
immediate pull request. Thanks.

/Jarkko

The following changes since commit 1306d8e1c09fdc8ecb9ef235e2116352f810f9c5:

  Merge tag 'tpmdd-next-20160927' of 
git://git.infradead.org/users/jjs/linux-tpmdd into ra-next (2016-09-27 19:21:37 
+1000)

are available in the git repository at:

  git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20161005

for you to fetch changes up to 65da72b7ddcdd8990e4783d09c7e86d90ccb4121:

  tpm: remove invalid min length check from tpm_do_selftest() (2016-10-05 
18:21:58 +0300)


tpmdd critical fix for Linux 4.9


Jarkko Sakkinen (1):
  tpm: remove invalid min length check from tpm_do_selftest()

 drivers/char/tpm/tpm-interface.c | 3 ---
 1 file changed, 3 deletions(-)