[linux-yocto] v5.2.x - stable updates comprising v5.2.23

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 5.2.x stable update "extension" primarily created for
the Yocto project, continuing from the first v5.2.22 post-EOL release.

This 5.2.22 release only contains about 22 mainline commits.  Rather
than continue the audit of what went into 5.3.8 - I jumped ahead to
5.3.11 in order to get the latest CVE embargo commits relating to
iTLB/tsx/TAA, as I assumed they would be of interest to people.

Folks will find in /sys/devices/system/cpu/vulnerabilities - alongside
spectre and meltdown, new files itlb_multihit and tsx_async_abort, and
can look them up in the documentation for more details.

I will circle back to 5.3.8+ content for the next v5.2.24 release I'll
be starting shortly.

The CVE was significant to KVM, and as such, the commits had a fairly
high footprint in that subsystem.  I used a code refactoring mainline
commit from between 5.2 and 5.3 in order to enable using the CVE related
KVM commits with as little alteration as possible.  Also possibly worth
a mention, is that post-5.2 the main kvm_lock went from being a spinlock
to a mutex.  Rather than risk any possible impact to -rt, I simply
retained it being a spin, and adjusted the CVE commits accordingly.

I've put this 5.2.23 queue through the usual testing; build testing on
x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis and
finally some sanity runtime tests on x86-64.

In addition, since there was a significant KVM footprint in the
changelog, I also built a defconfig with KVM and KVM_INTEL enabled, and
booted that same kernel as host and guest, on both kvm-intel enabled and
older non-kvm-intel enabled systems, and saw no obvious issues.

I did the signed tag just as per the previously released versions.
Please find a signed v5.2.23 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git/?h=linux-5.2.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-5.2.y.git

for merge to standard/base in linux-yocto-5.2 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-5.2.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 5.2.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v5.2.x - stable updates comprising v5.2.22

[Paul Gortmaker]

[Re: v5.2.x - stable updates comprising v5.2.22] On 10/11/2019 (Sun 22:36) 
Bruce Ashfield wrote:

> This is merged, that being said .. there are a couple of things that
> could use a second set of eyes.
> 
> 1) I had a preempt-rt conflict in fs/libfs.c. It looks like
> scan_positives() was introduced. The merge picked up a conflict, when
> really it should have just been the introduction of that new function
> and a drop of the old ones. But again, a 2nd set of eyes to see if I
> read it right would be nice.

Yes, it seems this -rt commit:

commit 037e1e5242b669920374c993cace7c3872257747
Author: Sebastian Andrzej Siewior 
Date:   Fri Oct 20 11:29:53 2017 +0200

fs/dcache: disable preemption on i_dir_seq's write side

bumps into this stable backport:

commit 60624198d203847694fe8f637fed6d67d8027370
Author: Al Viro 
Date:   Sun Sep 15 12:12:39 2019 -0400

Fix the locking in dcache_readdir() and friends

...and as usual, the merge conflict isn't really all that informative.
However, if you revert the -rt change, and then merge, and then re-apply
the -rt change, it is more clear.

In any case, here is a small patch to fixup the current preempt-rt
compile failures against v5.2/standard/preempt-rt/base


diff --git a/fs/libfs.c b/fs/libfs.c
index 81d210ba8e83..7ac2d4bb4735 100644
--- a/fs/libfs.c
+++ b/fs/libfs.c
@@ -125,8 +125,9 @@ static struct list_head *scan_positives(struct dentry 
*cursor,
}
}
spin_unlock(>d_lock);
-   dput(last);
-   return found;
+   dput(*res);
+   *res = found;
+   return p;
 }
 
 loff_t dcache_dir_lseek(struct file *file, loff_t offset, int whence)
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.45

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the *final* 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.44 release.

This final release closes out a run of 25 releases and about 4600
backports since GregKH stopped maintenance at v4.18.20, just under a
year ago.  I hope people have found the update extentsions useful during
that period; both Yocto users and "vanilla" 4.18.x users alike.

I didn't send an announce for 4.18.44, since I wanted to finish this
4.18.x run with the addition of the recent spectre-v1 (swapgs) variant
fixes.  But I wanted to also keep them separate to ease testing and
evaluation for integrators.  So the 44 is "normal" content, and the 45
is specific to spectre-v1/swapgs content, basically.

More specifically, the 4.18.44 release contains about 235 mainline
commits based on what was found in 4.19.51 --> 4.19.55 stable content.

The 4.18.45 release contains the swapgs (CVE-2019-1125) content, plus a
couple powerpc CVE fixes that caught my eye.  The x86 users can check:

 # cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
 Mitigation: usercopy/swapgs barriers and __user pointer sanitization

Check Documentation/admin-guide/hw-vuln/spectre.rst for more info.

I've put this *final* 4.18.45 queue through the usual testing; build
testing on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.  The 4.18.44 release
also got the same independent testing prior to starting 4.18.45.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.45 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.43

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.42 release.

There are about 125 commits here, based on the commits that were used
in the 4.19.[48/49/50] linux-stable releases.

A note to distro builders - normally there are no new Kconfig options
in stable, but here there is a new "NOUVEAU_LEGACY_CTX_SUPPORT" option.
The upstream decided that the easiest solution to avoid potential
security issues with the legacy code was to provide a way for distro
builders to opt out.  But it remains enabled by default so as to not
break any exising users who rely on it.

I suspect I'll have time to do one more final 4.18 stable backport
release.  Hopefully with the EOL messaging being in the last few
releases, this is no surprise to anyone, and people have their own
maintenance or migration plans in place and rolled out.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.43 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.42

[Paul Gortmaker]

[Re: v4.18.x - stable updates comprising v4.18.42] On 25/08/2019 (Sun 22:10) 
Bruce Ashfield wrote:

> On Sun, Aug 18, 2019 at 10:14 AM Paul Gortmaker
>  wrote:
> >
> > Bruce, Yocto kernel folks:
> >
> > Here is the next 4.18.x stable update "extension" primarily created
> > for the Yocto project, continuing from the previous v4.18.41 release.

[...]

> Hey Paul,
> 
> I was merging this tonight and ran into a nasty -rt merge conflict in
> kernel/irq_work.c. Can you take a look and send a resolution ? When I
> compared the 4.19-rt and 5.x-rt branches, I didn't see an obvious way
> to resolve things.

So it might not have been obvious, but there is a 4.19-rt resolution
buried in there in linux-stable-rt

commit e51f31ad716a485ed5bada8d367df60d6a99b9ac
Merge: 3cfcdc4d74dc 0df021b2e841
Author: Steven Rostedt (VMware) 
Date:   Fri Jun 14 12:54:23 2019 -0400
Merge tag 'v4.19.47' into v4.19-rt

This is the 4.19.47 stable release

 Conflicts:
drivers/char/random.c
kernel/irq_work.c

...and since the 4.18.42 irq_work.c is identical to 4.19.47, we can just
re-use Steve's conflict resolution by wholesale importing the 4.19-rt
version of his file after his merge.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.42

[Paul Gortmaker]

[Re: v4.18.x - stable updates comprising v4.18.42] On 25/08/2019 (Sun 22:10) 
Bruce Ashfield wrote:

> On Sun, Aug 18, 2019 at 10:14 AM Paul Gortmaker
>  wrote:
> >
> > Bruce, Yocto kernel folks:
> >
> > Here is the next 4.18.x stable update "extension" primarily created
> > for the Yocto project, continuing from the previous v4.18.41 release.
> >
> > There are about 150 commits here, based on the remaining commits that
> > were used in the 4.19.46/47 stable releases -- but not put into the
> > previous 4.10.40 release in order to keep the commit count reasonable.
> >
> > These 4.18 stable backport releases will be ending in September, as I
> > will be moving to working on newer kernels.  Hopefully with the same
> > messaging being in the last few releases, this is no surprise to anyone,
> > and people are in the final stages of getting their own maintenance or
> > migration plans in place and rolled out.
> >
> > I've put this 4.18.x queue through the usual testing; build testing
> > on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
> > and finally some sanity runtime tests on x86-64.
> >
> > I did the signed tag just as per the previously released versions.
> > Please find a signed v4.18.42 tag using this key:
> >
> 
> Hey Paul,
> 
> I was merging this tonight and ran into a nasty -rt merge conflict in
> kernel/irq_work.c. Can you take a look and send a resolution ? When I
> compared the 4.19-rt and 5.x-rt branches, I didn't see an obvious way
> to resolve things.

I will have a look.  Nothing in the application of patches to the
standard kernel indicated any similar conflict, so hopefully it won't be
a complex resolution.

P.
--

> 
> Bruce
> 
> > http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
> >
> > in the repo in the kernel.org directory here:
> >
> >   
> > https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
> >   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git
> >
> > for merge to standard/base in linux-yocto-4.18 and then out from there
> > into the other base and BSP branches.
> >
> > For those who are interested, the evolution of the commits is here:
> >
> >   
> > https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/
> >
> > This repo isn't needed for anything; it just exists for transparency and
> > so people can see the evolution of the raw commits that were originally
> > selected to create this 4.18.x release.
> >
> > Paul.
> 
> 
> 
> -- 
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.42

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.41 release.

There are about 150 commits here, based on the remaining commits that
were used in the 4.19.46/47 stable releases -- but not put into the
previous 4.10.40 release in order to keep the commit count reasonable.

These 4.18 stable backport releases will be ending in September, as I
will be moving to working on newer kernels.  Hopefully with the same
messaging being in the last few releases, this is no surprise to anyone,
and people are in the final stages of getting their own maintenance or
migration plans in place and rolled out.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.42 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] modules: always page-align module section allocations

[Paul Gortmaker]

[[linux-yocto] [PATCH] modules: always page-align module section allocations] 
On 16/08/2019 (Fri 15:36) zhe...@windriver.com wrote:

It helps maintainers if the version is embedded in the subject, like:

  [PATCH v4.18] modules: always page-align module section

> From: Jessica Yu 
> 
> Some arches (e.g., arm64, x86) have moved towards non-executable
> module_alloc() allocations for security hardening reasons. That means
> that the module loader will need to set the text section of a module to
> executable, regardless of whether or not CONFIG_STRICT_MODULE_RWX is set.
> 
> When CONFIG_STRICT_MODULE_RWX=y, module section allocations are always
> page-aligned to handle memory rwx permissions. On some arches with
> CONFIG_STRICT_MODULE_RWX=n however, when setting the module text to
> executable, the BUG_ON() in frob_text() gets triggered since module
> section allocations are not page-aligned when CONFIG_STRICT_MODULE_RWX=n.
> Since the set_memory_* API works with pages, and since we need to call
> set_memory_x() regardless of whether CONFIG_STRICT_MODULE_RWX is set, we
> might as well page-align all module section allocations for ease of
> managing rwx permissions of module sections (text, rodata, etc).
> 
> Fixes: 2eef1399a866 ("modules: fix BUG when load module with rodata=n")
> Reported-by: Martin Kaiser 
> Reported-by: Bartosz Golaszewski 
> Tested-by: David Lechner 
> Tested-by: Martin Kaiser 
> Tested-by: Bartosz Golaszewski 
> Signed-off-by: Jessica Yu 
> 
> commit38f054d549a869f22a02224cd276a27bf14b6171 upstream

Normally we put this right at the top of the long log.  Also this commit
ID appears bogus - it does not exist in mainline.

Also it seems very odd that the block of Signed-off lines are stuck in
the middle of the long log.

> 
> When loading modules with CONFIG_ARCH_HAS_STRICT_MODULE_RWX enabled and
> CONFIG_STRICT_MODULE_RWX disabled, the memory allocated for modules would
> not be page-aligned and cause the following BUG during frob_text.
> 
> [ cut here ]
> kernel BUG at kernel/module.c:1907!
> Internal error: Oops - BUG: 0 [#1] ARM
> Modules linked in:
> CPU: 0 PID: 89 Comm: systemd-modules Not tainted 5.3.0-rc2 #1
> Hardware name: ARM-Versatile (Device Tree Support)
> PC is at frob_text.constprop.0+0x2c/0x40
> LR is at load_module+0x14b4/0x1d28
> pc : []lr : []psr: 2013
> sp : ce44fe58  ip :   fp : 
> r10:   r9 : ce44feb8  r8 : 
> r7 : 0001  r6 : bf00032c  r5 : ce44ff40  r4 : bf000320
> r3 : bf000400  r2 : 0fff  r1 : 0220  r0 : bf00
> Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> Control: 00093177  Table: 0e4c  DAC: 0051
> Process systemd-modules (pid: 89, stack limit = 0x9fccc8dc)
> Stack: (0xce44fe58 to 0xce45)
> fe40:    cf1b05b8
> fe60: 0001 ce47cf08 bf002754 c07ae5d8 d0a2a484 bf002060 bf0004f8 
> fe80: b6d17910 c017cf1c ce47cf00 d0a29000 ce47cf00 ce44ff34 14fc 
> fea0:   bf00025c 0001   6e72656b 6c65
> fec0:        
> fee0:      c0ac9048 7fff 
> ff00: b6d17910 0005 017b c0009208 ce44e000  b6ebfe54 c008562c
> ff20: 7fff  0003 cefd28f8 0001 d0a29000 14fc 
> ff40: d0a292cb d0a29380 d0a29000 14fc d0a29f0c d0a29d90 d0a29a60 0520
> ff60: 0710 0718 0826    0708 0023
> ff80: 0024 001c  0016  c0ac9048 0041c620 
> ffa0:  c0009000 0041c620  0005 b6d17910  
> ffc0: 0041c620   017b 0041f078  004098b0 b6ebfe54
> ffe0: bedb6bc8 bedb6bb8 b6d0f91c b6c945a0 6010 0005  
> [] (frob_text.constprop.0) from [] 
> (load_module+0x14b4/0x1d28)
> [] (load_module) from [] (sys_finit_module+0xa0/0xc4)
> [] (sys_finit_module) from [] (ret_fast_syscall+0x0/0x50)
> Exception stack(0xce44ffa8 to 0xce44fff0)
> ffa0:   0041c620  0005 b6d17910  
> ffc0: 0041c620   017b 0041f078  004098b0 b6ebfe54
> ffe0: bedb6bc8 bedb6bb8 b6d0f91c b6c945a0
> Code: e7f001f2 e5931008 e1110002 0a01 (e7f001f2)
> ---[ end trace e904557128d9aed5 ]---
> 
> Signed-off-by: He Zhe 
> ---
> This is for linux-yocto-dev all branches.

The version information is important, and shouldnt be hidden down here.
If you put it within the [PATCH ] square bracket section, the
maintainer/merger person will see it and the "git am" will throw it away
once applied.

Paul.
--

> 
>  kernel/module.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/kernel/module.c b/kernel/module.c
> index 5933395..cd8df51 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ 

[linux-yocto] v4.18.x - stable updates comprising v4.18.41

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.40 release.

There are about 220 commits here, based on commits chosen from what were
used in the 4.19.46/47 stable releases -- plus some TCP related commits
that were of interest to reach ahead and source from newer 4.19 now.
Not all the 47 content was processed here, in order to keep the release
size sane.  The remainder will be considered for the 4.18.42 release.

And as we enter August, I need to again remind people that the creation
of these 4.18 stable backport releases will be ending relatively soon,
as I'll expect to be moving to newer kernels used in newer Yocto
releases.  So people need to get their own maintenance or migration
plans in place as soon as possible, if they have not yet done so.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.41 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.40

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.39 release.

There are about 260 commits here, based on commits chosen from what were
used in the 4.19.42/44/45 stable releases -- so another "batch" release.
The 4.19.43 content was the MDS stuff we handled in an expidited fashion
a couple releases ago.  No one subsystem is over-represented, so we can
count this as another "normal" stable release case.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.40 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.39

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.38 release.

There are about 180 commits here, based on commits chosen from what were
used in the 4.19.39/40/41 stable releases -- so another "batch" release,
if you will.  I don't think any one subsystem is over-represented, so we
can count this as a "normal" stable release case.

Since there isn't anything else news-worthy to report, I'll remind
people once again that these updates will most likely draw to a close
in a few months, so 4.18.x users should start planning accordingly.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.39 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.38

[Paul Gortmaker]

[Re: v4.18.x - stable updates comprising v4.18.38] On 16/05/2019 (Thu 16:47) 
Paul Gortmaker wrote:

[...]

> > The conflicts just look like one of the changes is already in my tree .. 
> > which
> > IIRC is the case, but it would be great if you could check the latest 
> > branches
> > and confirm the commit I should revert before merging this.
> 
> OK -- I'll have a look at doing the merge locally and let you know.

Your guess is correct, but it is three duplicates and not just one.

So, if we look at 4.18/standard base and run:

   git log --oneline --no-merges  ^v4.18.37 HEAD  net/ipv4/

   ecf31c809599 ip: frags: fix crash in ip_do_fragment()
   02fc22c5eb30 ip: use rb trees for IP frag queue.
   7a9f904c49aa ip: discard IPv4 datagrams with overlapping segments.

These are all part of the 4.18.38 content, but it appears that these
earlier backports in Yocto were done w/o stacking the dependencies
underneath so that they could be used as-is.  Apparently that meant
git-merge wasn't able to recognize the duplicated content, leading to a
needlessly complex merge.

However, nothing is stacked on top of them, so a LIFO rewind as:

   git revert ecf31c809599
   git revert 02fc22c5eb30
   git revert 7a9f904c49aa

...then allows a "git merge v4.18.38" to be 100% conflict free.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v4.18.x - stable updates comprising v4.18.38

[Paul Gortmaker]

[Re: v4.18.x - stable updates comprising v4.18.38] On 16/05/2019 (Thu 15:59) 
Bruce Ashfield wrote:

> 
> 
> On Wed, May 15, 2019 at 6:07 PM Paul Gortmaker 
> wrote:
> 
> Bruce, Yocto kernel folks:
> 
> Here is the next 4.18.x stable update "extension" primarily created
> for the Yocto project, continuing from the previous v4.18.37 release.

[...]

> There is a slight bias towards networking in the content here; it seems
> in v4.19, an ipv6 frag issue was best resolved by importing work that
> combined some ipv4/ipv6 code first.  And for 4.18 here, I had to extend
> that slightly by getting some related commits between 4.18 and 4.19.
> But after doing that, the related commits played nice together during
> application, and some basic ping6 tests didn't reveal any issues.

[...]

> v4.18.37 merged without problems, but I'm seeing something off with the .38
> tag:
> 
> CONFLICT (content): Merge conflict in net/ipv6/netfilter/nf_conntrack_reasm.c
> CONFLICT (content): Merge conflict in net/ipv4/ip_fragment.c
> CONFLICT (content): Merge conflict in net/ipv4/inet_fragment.c
> CONFLICT (content): Merge conflict in include/net/inet_frag.h

Heh, not too surprising, given my net/frag comment above.

> The conflicts just look like one of the changes is already in my tree .. which
> IIRC is the case, but it would be great if you could check the latest branches
> and confirm the commit I should revert before merging this.

OK -- I'll have a look at doing the merge locally and let you know.

Paul.
--
> 
> Bruce
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.38

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.37 release.

There is one trivial one line commit to fix a build error on PPC64 from
the MDS patches of v4.18.37 - which was also present in GregKH's stable
releases our v4.18.37 was based on.  That patch is 1st in the queue if
anyone is looking for it.  Greg also has the fix now, and so fingers
crossed that we don't see any more whole releases for a single bug-fix
for months and months.  

There are about 165 commits here, based on commits chosen from what were
used in the 4.19.37 and 4.19.38 stable releases.  I had most of this
work done before MDS came along, hence the close together releases.

There is a slight bias towards networking in the content here; it seems
in v4.19, an ipv6 frag issue was best resolved by importing work that
combined some ipv4/ipv6 code first.  And for 4.18 here, I had to extend
that slightly by getting some related commits between 4.18 and 4.19.
But after doing that, the related commits played nice together during
application, and some basic ping6 tests didn't reveal any issues.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.38 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.37

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.36 release.

There are just over 30 commits here, based only on commits chosen from
what was used in the MDS stable releases that came out today.

This content is specific to the MDS issue, both here and in 4.19.43. In
fact, to speed up turn around time, I didn't re-export the selected
commits from mainline, but used the 4.19.43 versions directly.  I also
set aside my work-in-progress content - it will be in the next release.

By inspecting the 4.14.119 release as well, I located an additional
patch that arrived in 4.19-rc1, and hence would also be needed here for
this 4.18.x release.  Other than that, the commit series in 4.14 and
4.19 are nearly identical, which gives another good sanity check on
things being complete and no hidden/implicit dependencies here.

For those that haven't (yet) heard about MDS, you can start with:
Documentation/admin-guide/hw-vuln/mds.rst
in kernels that have had updates applied.  It will give you keywords and
basic information that you can use to search out more details.

As this was x86 specific, I skipped the usual MIPS/ARM/PPC builds for
this one topic specific release.  I boot tested on x86-64 and checked
for the new MDS messages/content documented above.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.37 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.36

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.35 release.

There are just over 185 commits here, based on commits chosen from what
was used in the 4.19.35 and 4.19.36 stable releases.

I'd incorrectly stated in the previous release announcement that 4.18.35
was based on 4.19.33; rather it was based on 4.19.34 content.  Too many
version numbers all close together... in any case the full history of
the sourced and altered commits can be found in the 2nd repo below.

Again there is no one stand out feature with a bunch of fixes applied;
they seem fairly uniformly spread out over the tree.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I expect to be doing similar updates for approximately another four
months - but it is never to early for users to start thinking ahead.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.36 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 4.19-rt] Revert "mm: handle lru_add_drain_all for UP properly"

[Paul Gortmaker]

This reverts commit e6e9d6e290028b0a6b83b563fad9fafa7f1d515e.

It was a 4.19.31 backport of commit 6ea183d60c46 ("mm: handle
lru_add_drain_all for UP properly").  In summary, what that did
was to fix a possible harmless WARN_ON on non-SMP, introduced at
commit 4d43d395fed1 ("workqueue: Try to catch flush_work() without
INIT_WORK().") by adding non-SMP variants of lru functions.

The combination of that, with the -rt commit 473f14a9f234 ("mm:
perform lru_add_drain_all() remotely") at the merge of the two
results in the following build failure:

  mm/swap.c:736:2: error: #endif without #if

since the -rt change wants RT specific lru and the stable backport
wants non-SMP specific lru, and a chunk of the backport with
an #ifdef CONFIG_SMP is missing.

However, before we add a four way cluster of ifdeffery to handle all
cases, we note 4d43d395fed1 was added to the v5.1 release, and it
was not (currently) backported to any 4.19.x stable release - so it is
unclear to me why this commit was ever backported to 4.19.31 at all.

Further, we note this change was to mm/swap.c -- and by definition,
any preempt-rt deployment that uses swap for anything other than a
failure contingency mitigation is broken by design.

Given all that, I decided that the best path forward was to revert
the two of the three chunks of the backport that remain in the -rt
branch, and return us to the pre-4.19.31 merge behaviour for -rt.

Signed-off-by: Paul Gortmaker 

diff --git a/mm/swap.c b/mm/swap.c
index 7e0bcaf450a5..9217027671c8 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -325,6 +325,11 @@ static inline void activate_page_drain(int cpu)
 {
 }
 
+static bool need_activate_page_drain(int cpu)
+{
+   return false;
+}
+
 void activate_page(struct page *page)
 {
struct zone *zone = page_zone(page);
@@ -728,12 +733,6 @@ void lru_add_drain_all(void)
 
mutex_unlock();
 }
-#else
-void lru_add_drain_all(void)
-{
-   lru_add_drain();
-}
-#endif
 
 /**
  * release_pages - batched put_page()
-- 
2.7.4

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.34

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.33 release.

There are just over 160 commits here, based on commits chosen from what
was used in the recent 4.19.32 stable release.

That warrants an additional note - the 4.19.32 release contained powerpc
changes related to spectre stuff, which built on related commits added
between 4.18 and 4.19-rc1 releases.  So I had to circle back to that
window and pick up those prerequisites.  Fortunately older stable
releases like 4.14.x provided additional guidance on what that commit
list should contain.  That also uncovered a build fail in one of the
ppc64 defconfigs, which required backport of another recent fix.  That
said, the number of commits and the impact was nowhere near what we saw
on earlier kernel versions for x86-64 -- only about 2 doz. commits here.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.34 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

  
https://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git/?h=linux-4.18.y
  git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

  https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.33

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.32 release.

There are about 260 commits here, based on commits chosen from what
was used in the recent 4.19.31 stable release.  So, yes, another
bigger one, but still no one big feature/area was responsible.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.33 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.32

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.30 release.

There are about 165 commits here, based on commits chosen from what
were used in the existing 4.19.29 --> 4.19.30 stable releases.
Nothing unusual to report in this release, just the routine sort of
stable type commits once again.  Which is a good thing!

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.32 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 4.18-rt] of: phandle_cache merge fixup for preempt-rt

[Paul Gortmaker]

In yocto merge 5cc3fddf0e2a ("Merge branch 'v4.18/standard/base' into
v4.18/standard/preempt-rt/base") there was a conflict between the
backport of upstream b8a9ac1a5b99 ("of: of_node_get()/of_node_put() nodes
held in phandle cache") and the rt-specific commit b75caf08b721 ("of:
allocate / free phandle cache outside of the devtree_lock")

Unfortunately the conflict resolution left a shadow variable introduced
by the rt patch as undefined, resulting in:

drivers/of/base.c:120:2: error: 'shadow' undeclared (first use in this function)
  shadow = phandle_cache;
  ^~

drivers/of/base.c: In function 'of_populate_phandle_cache':
drivers/of/base.c:182:7: warning: 'shadow' is used uninitialized in this 
function [-Wuninitialized]

Here we create a merge fix-up that basically aligns the impacted code to
match what is currently found in the 4.19-rt (as of v4.19.15-rt12).

Reported-by: Yue Tao 
Signed-off-by: Paul Gortmaker 

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 904c7686f9d7..4a33ef482bcc 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -106,31 +106,34 @@ static u32 phandle_cache_mask;
 /*
  * Caller must hold devtree_lock.
  */
-static void __of_free_phandle_cache(void)
+static struct device_node** __of_free_phandle_cache(void)
 {
u32 cache_entries = phandle_cache_mask + 1;
u32 k;
+   struct device_node **shadow;
 
if (!phandle_cache)
-   return;
+   return NULL;
 
for (k = 0; k < cache_entries; k++)
of_node_put(phandle_cache[k]);
 
shadow = phandle_cache;
phandle_cache = NULL;
+   return shadow;
 }
 
 int of_free_phandle_cache(void)
 {
unsigned long flags;
+   struct device_node **shadow;
 
raw_spin_lock_irqsave(_lock, flags);
 
-   __of_free_phandle_cache();
+   shadow = __of_free_phandle_cache();
 
raw_spin_unlock_irqrestore(_lock, flags);
-
+   kfree(shadow);
return 0;
 }
 #if !defined(CONFIG_MODULES)
@@ -169,27 +172,24 @@ void of_populate_phandle_cache(void)
 
raw_spin_lock_irqsave(_lock, flags);
 
-   __of_free_phandle_cache();
+   shadow = __of_free_phandle_cache();
 
for_each_of_allnodes(np)
if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL)
phandles++;
 
-   raw_spin_unlock_irqrestore(_lock, flags);
-   kfree(shadow);
-
if (!phandles)
-   return;
+   goto out;
+   raw_spin_unlock_irqrestore(_lock, flags);
 
cache_entries = roundup_pow_of_two(phandles);
phandle_cache_mask = cache_entries - 1;
 
-   shadow = kcalloc(cache_entries, sizeof(*phandle_cache), GFP_KERNEL);
-
-   if (!shadow)
-   return;
+   phandle_cache = kcalloc(cache_entries, sizeof(*phandle_cache),
+   GFP_ATOMIC);
raw_spin_lock_irqsave(_lock, flags);
-   phandle_cache = shadow;
+   if (!phandle_cache)
+   goto out;
 
for_each_of_allnodes(np)
if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL) {
@@ -197,7 +197,9 @@ void of_populate_phandle_cache(void)
phandle_cache[np->phandle & phandle_cache_mask] = np;
}
 
+out:
raw_spin_unlock_irqrestore(_lock, flags);
+   kfree(shadow);
 }
 
 void __init of_core_init(void)
-- 
2.7.4

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.31

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.30 release.

There are about 125 commits here, based on commits chosen from what
were used in the existing 4.19.27 --> 4.19.28 stable releases.

Nothing unusual to report in this release, just the routine sort of
stable type commits.  There were a couple perf commits in 4.19.29 that
were of interest to people, so I reached ahead and got those now.  The
triage of the rest of the 4.19.29 content will be a part of the next
release - 4.18.32 - which will be underway soon.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.31 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.30

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.29 release.

There are about 245 commits here, based on commits chosen from what
were used in the existing 4.19.22 --> 4.19.26 stable releases.

The largest group of related commits in this series are 32 bit ARM
spectre related changes.  With some low level assembly changes involved,
I used the the 4.19-stable versions instead of directly backporting from
mainline like I normally do for everything else -- to capitalize on the
runtime testing and non-straightforward backports done by others with
more ARM32 experience.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.30 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.29

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.28 release.

There are about 275 commits here, based on commits chosen from what
was used in the existing 4.19.21 stable release that had over 300
backports, which is one of the larger stable releases ever to ship.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.29 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.28

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.27 release.

There are about 140 commits here, based on commits chosen from what
were used in the existing 4.19.19 --> 4.19.20 stable releases.  I would
have added more, but the 4.19.21 release has over 300 backports, so that
warrants a release of its own (fair warning of what to expect in 4.18.29)

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.28 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] Modify sysctl.conf

[Paul Gortmaker]

[[linux-yocto] Modify sysctl.conf] On 14/02/2019 (Thu 11:06) Franz Forstmayr 
wrote:

> Hi,
> 
> I have a board with more than one ethernet ports, which should get
> connected to the same network, at least for now. I wanted to prevent
> arp flux for my build and appended the procps recipe with following
> lines.

This list is meant for issues specific to the kernel(s) used in the
yocto project, even if the name doesn't really convey that very well.

For configuration issues like this, I suggest you google for the various
yocto mailing lists, and then pick the one that matches your issue the
best.

Good luck,
Paul.
--

> 
> do_install_prepend() {
> echo "net.ipv4.conf.all.arp_announce=1" >> ${WORKDIR}/sysctl.conf
> echo "net.ipv4.conf.all.arp_ignore=2" >> ${WORKDIR}/sysctl.conf
> }
> The sysctl.conf gets modified in my tmp/work folder, however the
> sysctl file doesn't get deployed to my rootfs? How to fix this issue.
> Further testing shows, that the sysctl.conf doesn't even got deployed
> without my bbappend.
> So, how to get this work, or is there a better way to modify the sysctl?
> 
> Franz
> -- 
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.27

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.26 release.

There are about 215 commits here, based on commits chosen from what
were used in the existing 4.19.16 --> 4.19.18 stable releases, so back
to "normal" vs. what was done for 4.18.26 content choices.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.27 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.26

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.25 release.

This release is slightly different in terms of how the commits were
chosen.  Instead of taking references from 4.19.x *stable* releases,
these commits are chosen from analysis of 4.19 *mainline* commits.

To explain further, imagine a commit added to 4.18 mainline, which had
an issue found and fixed in the content used to make the final 4.19
mainline release.  We would never see that commit in a 4.19.x stable
release, because it was already present in what was mainline 4.19; which
could be called "v4.19.0" if that helps explain things.  If the breakage
was found and fixed *after* v4.19 mainline, like say v4.20, then it
would be considered for backporting to v4.19.x stable, and hence we
should see it in our normal monitoring of the 4.19.x stable releases.

So, this attempts to close that gap.  We look at commits that have a
"Fixes:" tag that references 4.18 content, which is also a commit that
landed in the 4.18-4.19 development. There are about 50 commits here.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.26 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.25

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.24 release.

There are about 125 commits here, based on commits chosen from what
was used in the existing 4.19.15 stable release.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.25 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.24

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.23 release.

There are about 230 commits here, based on commits chosen from what
was used in existing 4.19.12 to 4.19.14 (inclusive) stable releases.

Things seem to remain "normal" -- with just basically one commit per
each issue.  No one subsystem or arch or CVE with lots of changes.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released versions.
Please find a signed v4.18.24 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
-- 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.23

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.22 release.

There are about 235 commits here, based on commits chosen from what
was used in existing 4.19.9 to 4.19.11 (inclusive) stable releases.

Things are back to "normal" in that we seem to have the desired case
of "one issue -- one commit" vs. the spectre CVEs which required many
backports of mainline commits just for one CVE fix.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released 4.18.212

Please find a signed v4.18.23 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

I think it is safe to say this will be the last 4.18 release that I'll
be doing this year.  :)

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.22

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the next 4.18.x stable update "extension" primarily created
for the Yocto project, continuing from the previous v4.18.21 release.

There are about 250 commits here, based on commits chosen from what
was used in existing 4.19.6 to 4.19.8 stable releases.

And it wouldn't be a proper release if there weren't over two dozen
commits related to the spectre variant of the week, so we have that
in this batch as part of the above.

I've put this 4.18.x queue through the usual testing; build testing
on x86-64/32, ARM-64/32, PPC and MIPS, plus some static analysis
and finally some sanity runtime tests on x86-64.

I did the signed tag just as per the previously released 4.18.21.

Please find a signed v4.18.22 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.18.x - stable updates comprising v4.18.21

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the first 4.18.x stable update "extension" primarily created
for the Yocto project, continuing on top of the v4.18.20 kernel.

As some may already be aware, the v4.18.20 was the final release done
by Greg KH and team, and so just like was done for 4.12.x and 4.8.x;
the releases like this will monitor other active releases and use that
information to select appropriate commits for application to 4.18.x

Once again, the commits are applied to a vanilla 4.18.20 baseline, and
as there is nothing Yocto specific in the content, anyone using a 4.18.x
baseline kernel is welcome to make use of this work.  All of the commits
found here are mainline backports, as per usual.

There are about 135 commits here, based on commits chosen from what
was used in existing 4.19.4 and 4.19.5 stable releases.  The 4.19.3
was released at the same time as 4.18.20 and hence represents a
synchronization or starting point for this maintenance extension.

The 4.19 versions I was auditing contained batch updates from DaveM in
the networking department, and hence that is represented significantly
here in these commits.

I've put this 4.18.x queue through the usual testing that I figured made
sense; build testing on x86-64, ARM-64, ARM-32, PPC and MIPS, plus some
static analysis and sanity runtime tests on x86-64.

I did the signed tag just as per the previously released 4.12/4.8 versions.

Please find a signed v4.18.21 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.18.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.18.y.git

for merge to standard/base in linux-yocto-4.18 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.18.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.18.x release.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 10/10] btrfs: tree-checker: Verify block_group_item

[Paul Gortmaker]

From: Qu Wenruo 

commit fce466eab7ac6baa9d2dcd88abcf945be3d4a089 upstream.

A crafted image with invalid block group items could make free space cache
code to cause panic.

We could detect such invalid block group item by checking:
1) Item size
   Known fixed value.
2) Block group size (key.offset)
   We have an upper limit on block group item (10G)
3) Chunk objectid
   Known fixed value.
4) Type
   Only 4 valid type values, DATA, METADATA, SYSTEM and DATA|METADATA.
   No more than 1 bit set for profile type.
5) Used space
   No more than the block group size.

This should allow btrfs to detect and refuse to mount the crafted image.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=199849
Reported-by: Xu Wen 
Signed-off-by: Qu Wenruo 
Reviewed-by: Gu Jinxiang 
Reviewed-by: Nikolay Borisov 
Tested-by: Gu Jinxiang 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Paul Gortmaker 
---
 fs/btrfs/tree-checker.c | 100 
 fs/btrfs/volumes.c  |   2 +-
 fs/btrfs/volumes.h  |   2 +
 3 files changed, 103 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index d014af352ce0..db835635372f 100644
--- a/fs/btrfs/tree-checker.c
+++ b/fs/btrfs/tree-checker.c
@@ -19,6 +19,7 @@
 #include "tree-checker.h"
 #include "disk-io.h"
 #include "compression.h"
+#include "volumes.h"
 
 /*
  * Error message should follow the following format:
@@ -353,6 +354,102 @@ static int check_dir_item(struct btrfs_fs_info *fs_info,
return 0;
 }
 
+__printf(4, 5)
+__cold
+static void block_group_err(const struct btrfs_fs_info *fs_info,
+   const struct extent_buffer *eb, int slot,
+   const char *fmt, ...)
+{
+   struct btrfs_key key;
+   struct va_format vaf;
+   va_list args;
+
+   btrfs_item_key_to_cpu(eb, , slot);
+   va_start(args, fmt);
+
+   vaf.fmt = fmt;
+   vaf.va = 
+
+   btrfs_crit(fs_info,
+   "corrupt %s: root=%llu block=%llu slot=%d bg_start=%llu bg_len=%llu, 
%pV",
+   btrfs_header_level(eb) == 0 ? "leaf" : "node",
+   btrfs_header_owner(eb), btrfs_header_bytenr(eb), slot,
+   key.objectid, key.offset, );
+   va_end(args);
+}
+
+static int check_block_group_item(struct btrfs_fs_info *fs_info,
+ struct extent_buffer *leaf,
+ struct btrfs_key *key, int slot)
+{
+   struct btrfs_block_group_item bgi;
+   u32 item_size = btrfs_item_size_nr(leaf, slot);
+   u64 flags;
+   u64 type;
+
+   /*
+* Here we don't really care about alignment since extent allocator can
+* handle it.  We care more about the size, as if one block group is
+* larger than maximum size, it's must be some obvious corruption.
+*/
+   if (key->offset > BTRFS_MAX_DATA_CHUNK_SIZE || key->offset == 0) {
+   block_group_err(fs_info, leaf, slot,
+   "invalid block group size, have %llu expect (0, %llu]",
+   key->offset, BTRFS_MAX_DATA_CHUNK_SIZE);
+   return -EUCLEAN;
+   }
+
+   if (item_size != sizeof(bgi)) {
+   block_group_err(fs_info, leaf, slot,
+   "invalid item size, have %u expect %zu",
+   item_size, sizeof(bgi));
+   return -EUCLEAN;
+   }
+
+   read_extent_buffer(leaf, , btrfs_item_ptr_offset(leaf, slot),
+  sizeof(bgi));
+   if (btrfs_block_group_chunk_objectid() !=
+   BTRFS_FIRST_CHUNK_TREE_OBJECTID) {
+   block_group_err(fs_info, leaf, slot,
+   "invalid block group chunk objectid, have %llu expect %llu",
+   btrfs_block_group_chunk_objectid(),
+   BTRFS_FIRST_CHUNK_TREE_OBJECTID);
+   return -EUCLEAN;
+   }
+
+   if (btrfs_block_group_used() > key->offset) {
+   block_group_err(fs_info, leaf, slot,
+   "invalid block group used, have %llu expect [0, %llu)",
+   btrfs_block_group_used(), key->offset);
+   return -EUCLEAN;
+   }
+
+   flags = btrfs_block_group_flags();
+   if (hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK) > 1) {
+   block_group_err(fs_info, leaf, slot,
+"invalid profile flags, have 0x%llx (%lu bits set) expect no more than 1 bit 
set",
+   flags & BTRFS_BLOCK_GROUP_PROFILE_MASK,
+   hweight64(flags & BTRFS_BLOCK_GROUP_PROFILE_MASK));
+   return -EUCLEAN;
+   }
+
+   type = flags & BTRFS_BLOCK_GROUP_TYPE_MASK;
+   if (type != BTRFS_BLOCK

[linux-yocto] [PATCH 07/10] btrfs: Check that each block group has corresponding chunk at mount time

[Paul Gortmaker]

From: Qu Wenruo 

commit 514c7dca85a0bf40be984dab0b477403a6db901f upstream.

A crafted btrfs image with incorrect chunk<->block group mapping will
trigger a lot of unexpected things as the mapping is essential.

Although the problem can be caught by block group item checker
added in "btrfs: tree-checker: Verify block_group_item", it's still not
sufficient.  A sufficiently valid block group item can pass the check
added by the mentioned patch but could fail to match the existing chunk.

This patch will add extra block group -> chunk mapping check, to ensure
we have a completely matching (start, len, flags) chunk for each block
group at mount time.

Here we reuse the original helper find_first_block_group(), which is
already doing the basic bg -> chunk checks, adding further checks of the
start/len and type flags.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=199837
Reported-by: Xu Wen 
Signed-off-by: Qu Wenruo 
Reviewed-by: Su Yue 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Paul Gortmaker 
---
 fs/btrfs/extent-tree.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 4ab0bccfa281..9c0f9d7d4c73 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -9716,6 +9716,8 @@ static int find_first_block_group(struct btrfs_fs_info 
*fs_info,
int ret = 0;
struct btrfs_key found_key;
struct extent_buffer *leaf;
+   struct btrfs_block_group_item bg;
+   u64 flags;
int slot;
 
ret = btrfs_search_slot(NULL, root, key, path, 0, 0);
@@ -9750,8 +9752,32 @@ static int find_first_block_group(struct btrfs_fs_info 
*fs_info,
"logical %llu len %llu found bg but no related chunk",
  found_key.objectid, found_key.offset);
ret = -ENOENT;
+   } else if (em->start != found_key.objectid ||
+  em->len != found_key.offset) {
+   btrfs_err(fs_info,
+   "block group %llu len %llu mismatch with chunk %llu len %llu",
+ found_key.objectid, found_key.offset,
+ em->start, em->len);
+   ret = -EUCLEAN;
} else {
-   ret = 0;
+   read_extent_buffer(leaf, ,
+   btrfs_item_ptr_offset(leaf, slot),
+   sizeof(bg));
+   flags = btrfs_block_group_flags() &
+   BTRFS_BLOCK_GROUP_TYPE_MASK;
+
+   if (flags != (em->map_lookup->type &
+ BTRFS_BLOCK_GROUP_TYPE_MASK)) {
+   btrfs_err(fs_info,
+"block group %llu len %llu type flags 0x%llx mismatch with chunk type flags 
0x%llx",
+   found_key.objectid,
+   found_key.offset, flags,
+   (BTRFS_BLOCK_GROUP_TYPE_MASK &
+em->map_lookup->type));
+   ret = -EUCLEAN;
+   } else {
+   ret = 0;
+   }
}
free_extent_map(em);
goto out;
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 09/10] btrfs: Introduce mount time chunk <-> dev extent mapping check

[Paul Gortmaker]

From: Qu Wenruo 

commit cf90d884b347c50a1e8c1effc4093e497dd68b4b upstream.

This patch will introduce chunk <-> dev extent mapping check, to protect
us against invalid dev extents or chunks.

Since chunk mapping is the fundamental infrastructure of btrfs, extra
check at mount time could prevent a lot of unexpected behavior (BUG_ON).

Reported-by: Xu Wen 
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200403
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200407
Signed-off-by: Qu Wenruo 
Reviewed-by: Su Yue 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Paul Gortmaker 
---
 fs/btrfs/disk-io.c |   7 ++
 fs/btrfs/volumes.c | 184 +
 fs/btrfs/volumes.h |   2 +
 3 files changed, 193 insertions(+)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 891b1aab3480..0d8be8e5e949 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3077,6 +3077,13 @@ int open_ctree(struct super_block *sb,
fs_info->generation = generation;
fs_info->last_trans_committed = generation;
 
+   ret = btrfs_verify_dev_extents(fs_info);
+   if (ret) {
+   btrfs_err(fs_info,
+ "failed to verify dev extents against chunks: %d",
+ ret);
+   goto fail_block_groups;
+   }
ret = btrfs_recover_balance(fs_info);
if (ret) {
btrfs_err(fs_info, "failed to recover balance: %d", ret);
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 463e3dc34e1e..5c640994a129 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -6580,6 +6580,7 @@ static int read_one_chunk(struct btrfs_fs_info *fs_info, 
struct btrfs_key *key,
map->stripe_len = btrfs_chunk_stripe_len(leaf, chunk);
map->type = btrfs_chunk_type(leaf, chunk);
map->sub_stripes = btrfs_chunk_sub_stripes(leaf, chunk);
+   map->verified_stripes = 0;
for (i = 0; i < num_stripes; i++) {
map->stripes[i].physical =
btrfs_stripe_offset_nr(leaf, chunk, i);
@@ -7439,3 +7440,186 @@ void btrfs_reset_fs_info_ptr(struct btrfs_fs_info 
*fs_info)
fs_devices = fs_devices->seed;
}
 }
+
+
+static u64 calc_stripe_length(u64 type, u64 chunk_len, int num_stripes)
+{
+   int index = btrfs_bg_flags_to_raid_index(type);
+   int ncopies = btrfs_raid_array[index].ncopies;
+   int data_stripes;
+
+   switch (type & BTRFS_BLOCK_GROUP_PROFILE_MASK) {
+   case BTRFS_BLOCK_GROUP_RAID5:
+   data_stripes = num_stripes - 1;
+   break;
+   case BTRFS_BLOCK_GROUP_RAID6:
+   data_stripes = num_stripes - 2;
+   break;
+   default:
+   data_stripes = num_stripes / ncopies;
+   break;
+   }
+   return div_u64(chunk_len, data_stripes);
+}
+
+static int verify_one_dev_extent(struct btrfs_fs_info *fs_info,
+u64 chunk_offset, u64 devid,
+u64 physical_offset, u64 physical_len)
+{
+   struct extent_map_tree *em_tree = _info->mapping_tree.map_tree;
+   struct extent_map *em;
+   struct map_lookup *map;
+   u64 stripe_len;
+   bool found = false;
+   int ret = 0;
+   int i;
+
+   read_lock(_tree->lock);
+   em = lookup_extent_mapping(em_tree, chunk_offset, 1);
+   read_unlock(_tree->lock);
+
+   if (!em) {
+   btrfs_err(fs_info,
+"dev extent physical offset %llu on devid %llu doesn't have corresponding 
chunk",
+ physical_offset, devid);
+   ret = -EUCLEAN;
+   goto out;
+   }
+
+   map = em->map_lookup;
+   stripe_len = calc_stripe_length(map->type, em->len, map->num_stripes);
+   if (physical_len != stripe_len) {
+   btrfs_err(fs_info,
+"dev extent physical offset %llu on devid %llu length doesn't match chunk 
%llu, have %llu expect %llu",
+ physical_offset, devid, em->start, physical_len,
+ stripe_len);
+   ret = -EUCLEAN;
+   goto out;
+   }
+
+   for (i = 0; i < map->num_stripes; i++) {
+   if (map->stripes[i].dev->devid == devid &&
+   map->stripes[i].physical == physical_offset) {
+   found = true;
+   if (map->verified_stripes >= map->num_stripes) {
+   btrfs_err(fs_info,
+   "too many dev extents for chunk %llu found",
+ em->start);
+   ret = -EUCLEAN;
+   goto out;
+   }
+   map->verified_stripes++;
+ 

[linux-yocto] [PATCH 08/10] btrfs: Verify that every chunk has corresponding block group at mount time

[Paul Gortmaker]

From: Qu Wenruo 

commit 7ef49515fa6727cb4b6f2f5b0ffbc5fc20a9f8c6 upstream.

If a crafted image has missing block group items, it could cause
unexpected behavior and breaks the assumption of 1:1 chunk<->block group
mapping.

Although we have the block group -> chunk mapping check, we still need
chunk -> block group mapping check.

This patch will do extra check to ensure each chunk has its
corresponding block group.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=199847
Reported-by: Xu Wen 
Signed-off-by: Qu Wenruo 
Reviewed-by: Gu Jinxiang 
Reviewed-by: David Sterba 
Signed-off-by: David Sterba 
Signed-off-by: Paul Gortmaker 
---
 fs/btrfs/extent-tree.c | 58 +-
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 9c0f9d7d4c73..e942f7be 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -10028,6 +10028,62 @@ btrfs_create_block_group_cache(struct btrfs_fs_info 
*fs_info,
return cache;
 }
 
+
+/*
+ * Iterate all chunks and verify that each of them has the corresponding block
+ * group
+ */
+static int check_chunk_block_group_mappings(struct btrfs_fs_info *fs_info)
+{
+   struct btrfs_mapping_tree *map_tree = _info->mapping_tree;
+   struct extent_map *em;
+   struct btrfs_block_group_cache *bg;
+   u64 start = 0;
+   int ret = 0;
+
+   while (1) {
+   read_lock(_tree->map_tree.lock);
+   /*
+* lookup_extent_mapping will return the first extent map
+* intersecting the range, so setting @len to 1 is enough to
+* get the first chunk.
+*/
+   em = lookup_extent_mapping(_tree->map_tree, start, 1);
+   read_unlock(_tree->map_tree.lock);
+   if (!em)
+   break;
+
+   bg = btrfs_lookup_block_group(fs_info, em->start);
+   if (!bg) {
+   btrfs_err(fs_info,
+   "chunk start=%llu len=%llu doesn't have corresponding block group",
+em->start, em->len);
+   ret = -EUCLEAN;
+   free_extent_map(em);
+   break;
+   }
+   if (bg->key.objectid != em->start ||
+   bg->key.offset != em->len ||
+   (bg->flags & BTRFS_BLOCK_GROUP_TYPE_MASK) !=
+   (em->map_lookup->type & BTRFS_BLOCK_GROUP_TYPE_MASK)) {
+   btrfs_err(fs_info,
+"chunk start=%llu len=%llu flags=0x%llx doesn't match block group start=%llu 
len=%llu flags=0x%llx",
+   em->start, em->len,
+   em->map_lookup->type & 
BTRFS_BLOCK_GROUP_TYPE_MASK,
+   bg->key.objectid, bg->key.offset,
+   bg->flags & BTRFS_BLOCK_GROUP_TYPE_MASK);
+   ret = -EUCLEAN;
+   free_extent_map(em);
+   btrfs_put_block_group(bg);
+   break;
+   }
+   start = em->start + em->len;
+   free_extent_map(em);
+   btrfs_put_block_group(bg);
+   }
+   return ret;
+}
+
 int btrfs_read_block_groups(struct btrfs_fs_info *info)
 {
struct btrfs_path *path;
@@ -10201,7 +10257,7 @@ int btrfs_read_block_groups(struct btrfs_fs_info *info)
 
btrfs_add_raid_kobjects(info);
init_global_block_rsv(info);
-   ret = 0;
+   ret = check_chunk_block_group_mappings(info);
 error:
btrfs_free_path(path);
return ret;
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 05/10] ip: use rb trees for IP frag queue.

[Paul Gortmaker]

From: Peter Oskolkov 

commit fa0f527358bd900ef92f925878ed6bfbd51305cc upstream.

Similar to TCP OOO RX queue, it makes sense to use rb trees to store
IP fragments, so that OOO fragments are inserted faster.

Tested:

- a follow-up patch contains a rather comprehensive ip defrag
  self-test (functional)
- ran neper `udp_stream -c -H  -F 100 -l 300 -T 20`:
netstat --statistics
Ip:
282078937 total packets received
0 forwarded
0 incoming packets discarded
946760 incoming packets delivered
18743456 requests sent out
101 fragments dropped after timeout
282077129 reassemblies required
944952 packets reassembled ok
262734239 packet reassembles failed
   (The numbers/stats above are somewhat better re:
reassemblies vs a kernel without this patchset. More
comprehensive performance testing TBD).

Reported-by: Jann Horn 
Reported-by: Juha-Matti Tilli 
Suggested-by: Eric Dumazet 
Signed-off-by: Peter Oskolkov 
Signed-off-by: Eric Dumazet 
Cc: Florian Westphal 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker 
---
 include/linux/skbuff.h  |   9 +-
 include/net/inet_frag.h |   3 +-
 net/ipv4/inet_fragment.c|  16 +--
 net/ipv4/ip_fragment.c  | 182 ++--
 net/ipv6/netfilter/nf_conntrack_reasm.c |   1 +
 net/ipv6/reassembly.c   |   1 +
 6 files changed, 121 insertions(+), 91 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index e533b51fccfe..a01dff03681c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -675,12 +675,15 @@ struct sk_buff {
 * UDP receive path is one user.
 */
unsigned long   dev_scratch;
-   int ip_defrag_offset;
};
};
-   struct rb_node  rbnode; /* used in netem & tcp stack */
+   struct rb_node  rbnode; /* used in netem, ip4 defrag, and tcp 
stack */
+   };
+
+   union {
+   struct sock *sk;
+   int ip_defrag_offset;
};
-   struct sock *sk;
 
union {
ktime_t tstamp;
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index ed07e3786d98..e4c71a7644be 100644
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -75,7 +75,8 @@ struct inet_frag_queue {
struct timer_list   timer;
spinlock_t  lock;
refcount_t  refcnt;
-   struct sk_buff  *fragments;
+   struct sk_buff  *fragments;  /* Used in IPv6. */
+   struct rb_root  rb_fragments; /* Used in IPv4. */
struct sk_buff  *fragments_tail;
ktime_t stamp;
int len;
diff --git a/net/ipv4/inet_fragment.c b/net/ipv4/inet_fragment.c
index 0d70608cc2e1..9cabfc31012d 100644
--- a/net/ipv4/inet_fragment.c
+++ b/net/ipv4/inet_fragment.c
@@ -136,12 +136,16 @@ void inet_frag_destroy(struct inet_frag_queue *q)
fp = q->fragments;
nf = q->net;
f = nf->f;
-   while (fp) {
-   struct sk_buff *xp = fp->next;
-
-   sum_truesize += fp->truesize;
-   kfree_skb(fp);
-   fp = xp;
+   if (fp) {
+   do {
+   struct sk_buff *xp = fp->next;
+
+   sum_truesize += fp->truesize;
+   kfree_skb(fp);
+   fp = xp;
+   } while (fp);
+   } else {
+   sum_truesize = skb_rbtree_purge(>rb_fragments);
}
sum = sum_truesize + f->qsize;
 
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 960bf5eab59f..0e8f8de77e71 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -136,7 +136,7 @@ static void ip_expire(struct timer_list *t)
 {
struct inet_frag_queue *frag = from_timer(frag, t, timer);
const struct iphdr *iph;
-   struct sk_buff *head;
+   struct sk_buff *head = NULL;
struct net *net;
struct ipq *qp;
int err;
@@ -152,14 +152,31 @@ static void ip_expire(struct timer_list *t)
 
ipq_kill(qp);
__IP_INC_STATS(net, IPSTATS_MIB_REASMFAILS);
-
-   head = qp->q.fragments;
-
__IP_INC_STATS(net, IPSTATS_MIB_REASMTIMEOUT);
 
-   if (!(qp->q.flags & INET_FRAG_FIRST_IN) || !head)
+   if (!qp->q.flags & INET_FRAG_FIRST_IN)
goto out;
 
+   /* sk_buff::dev and sk_buff::rbnode are unionized. So we
+* pull the head out of the tree in order to be able to
+* deal with head->dev.
+*/
+   if (qp->q.fragments) {
+   head = qp->

[linux-yocto] [PATCH 04/10] net: modify skb_rbtree_purge to return the truesize of all purged skbs.

[Paul Gortmaker]

From: Peter Oskolkov 

commit 385114dec8a49b5e5945e77ba7de6356106713f4 upstream.

Tested: see the next patch is the series.

Suggested-by: Eric Dumazet 
Signed-off-by: Peter Oskolkov 
Signed-off-by: Eric Dumazet 
Cc: Florian Westphal 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker 
---
 include/linux/skbuff.h | 2 +-
 net/core/skbuff.c  | 6 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 610a201126ee..e533b51fccfe 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2580,7 +2580,7 @@ static inline void __skb_queue_purge(struct sk_buff_head 
*list)
kfree_skb(skb);
 }
 
-void skb_rbtree_purge(struct rb_root *root);
+unsigned int skb_rbtree_purge(struct rb_root *root);
 
 void *netdev_alloc_frag(unsigned int fragsz);
 
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 3680912f056a..e32897cd8492 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -2855,23 +2855,27 @@ EXPORT_SYMBOL(skb_queue_purge);
 /**
  * skb_rbtree_purge - empty a skb rbtree
  * @root: root of the rbtree to empty
+ * Return value: the sum of truesizes of all purged skbs.
  *
  * Delete all buffers on an _buff rbtree. Each buffer is removed from
  * the list and one reference dropped. This function does not take
  * any lock. Synchronization should be handled by the caller (e.g., TCP
  * out-of-order queue is protected by the socket lock).
  */
-void skb_rbtree_purge(struct rb_root *root)
+unsigned int skb_rbtree_purge(struct rb_root *root)
 {
struct rb_node *p = rb_first(root);
+   unsigned int sum = 0;
 
while (p) {
struct sk_buff *skb = rb_entry(p, struct sk_buff, rbnode);
 
p = rb_next(p);
rb_erase(>rbnode, root);
+   sum += skb->truesize;
kfree_skb(skb);
}
+   return sum;
 }
 
 /**
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 06/10] btrfs: validate type when reading a chunk

[Paul Gortmaker]

From: Gu Jinxiang 

commit 315409b0098fb2651d86553f0436b70502b29bb2 upstream.

Reported in https://bugzilla.kernel.org/show_bug.cgi?id=199839, with an
image that has an invalid chunk type but does not return an error.

Add chunk type check in btrfs_check_chunk_valid, to detect the wrong
type combinations.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=199839
Reported-by: Xu Wen 
Reviewed-by: Qu Wenruo 
Signed-off-by: Gu Jinxiang 
Signed-off-by: David Sterba 
Signed-off-by: Paul Gortmaker 
---
 fs/btrfs/volumes.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 1a22c0ecaf67..463e3dc34e1e 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -6428,6 +6428,8 @@ static int btrfs_check_chunk_valid(struct btrfs_fs_info 
*fs_info,
u16 num_stripes;
u16 sub_stripes;
u64 type;
+   u64 features;
+   bool mixed = false;
 
length = btrfs_chunk_length(leaf, chunk);
stripe_len = btrfs_chunk_stripe_len(leaf, chunk);
@@ -6466,6 +6468,32 @@ static int btrfs_check_chunk_valid(struct btrfs_fs_info 
*fs_info,
  btrfs_chunk_type(leaf, chunk));
return -EIO;
}
+
+   if ((type & BTRFS_BLOCK_GROUP_TYPE_MASK) == 0) {
+   btrfs_err(fs_info, "missing chunk type flag: 0x%llx", type);
+   return -EIO;
+   }
+
+   if ((type & BTRFS_BLOCK_GROUP_SYSTEM) &&
+   (type & (BTRFS_BLOCK_GROUP_METADATA | BTRFS_BLOCK_GROUP_DATA))) {
+   btrfs_err(fs_info,
+   "system chunk with data or metadata type: 0x%llx", 
type);
+   return -EIO;
+   }
+
+   features = btrfs_super_incompat_flags(fs_info->super_copy);
+   if (features & BTRFS_FEATURE_INCOMPAT_MIXED_GROUPS)
+   mixed = true;
+
+   if (!mixed) {
+   if ((type & BTRFS_BLOCK_GROUP_METADATA) &&
+   (type & BTRFS_BLOCK_GROUP_DATA)) {
+   btrfs_err(fs_info,
+   "mixed chunk type in non-mixed mode: 0x%llx", type);
+   return -EIO;
+   }
+   }
+
if ((type & BTRFS_BLOCK_GROUP_RAID10 && sub_stripes != 2) ||
(type & BTRFS_BLOCK_GROUP_RAID1 && num_stripes < 1) ||
(type & BTRFS_BLOCK_GROUP_RAID5 && num_stripes < 2) ||
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 03/10] ip: discard IPv4 datagrams with overlapping segments.

[Paul Gortmaker]

From: Peter Oskolkov 

commit 7969e5c40dfd04799d4341f1b7cd266b6e47f227 upstream.

This behavior is required in IPv6, and there is little need
to tolerate overlapping fragments in IPv4. This change
simplifies the code and eliminates potential DDoS attack vectors.

Tested: ran ip_defrag selftest (not yet available uptream).

Suggested-by: David S. Miller 
Signed-off-by: Peter Oskolkov 
Signed-off-by: Eric Dumazet 
Cc: Florian Westphal 
Acked-by: Stephen Hemminger 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker 
---
 include/uapi/linux/snmp.h |  1 +
 net/ipv4/ip_fragment.c| 75 ---
 net/ipv4/proc.c   |  1 +
 3 files changed, 21 insertions(+), 56 deletions(-)

diff --git a/include/uapi/linux/snmp.h b/include/uapi/linux/snmp.h
index 750d89120335..e908dd0f7577 100644
--- a/include/uapi/linux/snmp.h
+++ b/include/uapi/linux/snmp.h
@@ -56,6 +56,7 @@ enum
IPSTATS_MIB_ECT1PKTS,   /* InECT1Pkts */
IPSTATS_MIB_ECT0PKTS,   /* InECT0Pkts */
IPSTATS_MIB_CEPKTS, /* InCEPkts */
+   IPSTATS_MIB_REASM_OVERLAPS, /* ReasmOverlaps */
__IPSTATS_MIB_MAX
 };
 
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index d14d741fb05e..960bf5eab59f 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -277,6 +277,7 @@ static int ip_frag_reinit(struct ipq *qp)
 /* Add new segment to existing queue. */
 static int ip_frag_queue(struct ipq *qp, struct sk_buff *skb)
 {
+   struct net *net = container_of(qp->q.net, struct net, ipv4.frags);
struct sk_buff *prev, *next;
struct net_device *dev;
unsigned int fragsize;
@@ -357,65 +358,23 @@ static int ip_frag_queue(struct ipq *qp, struct sk_buff 
*skb)
}
 
 found:
-   /* We found where to put this one.  Check for overlap with
-* preceding fragment, and, if needed, align things so that
-* any overlaps are eliminated.
+   /* RFC5722, Section 4, amended by Errata ID : 3089
+*  When reassembling an IPv6 datagram, if
+*   one or more its constituent fragments is determined to be an
+*   overlapping fragment, the entire datagram (and any constituent
+*   fragments) MUST be silently discarded.
+*
+* We do the same here for IPv4.
 */
-   if (prev) {
-   int i = (prev->ip_defrag_offset + prev->len) - offset;
 
-   if (i > 0) {
-   offset += i;
-   err = -EINVAL;
-   if (end <= offset)
-   goto err;
-   err = -ENOMEM;
-   if (!pskb_pull(skb, i))
-   goto err;
-   if (skb->ip_summed != CHECKSUM_UNNECESSARY)
-   skb->ip_summed = CHECKSUM_NONE;
-   }
-   }
+   /* Is there an overlap with the previous fragment? */
+   if (prev &&
+   (prev->ip_defrag_offset + prev->len) > offset)
+   goto discard_qp;
 
-   err = -ENOMEM;
-
-   while (next && next->ip_defrag_offset < end) {
-   int i = end - next->ip_defrag_offset; /* overlap is 'i' bytes */
-
-   if (i < next->len) {
-   int delta = -next->truesize;
-
-   /* Eat head of the next overlapped fragment
-* and leave the loop. The next ones cannot overlap.
-*/
-   if (!pskb_pull(next, i))
-   goto err;
-   delta += next->truesize;
-   if (delta)
-   add_frag_mem_limit(qp->q.net, delta);
-   next->ip_defrag_offset += i;
-   qp->q.meat -= i;
-   if (next->ip_summed != CHECKSUM_UNNECESSARY)
-   next->ip_summed = CHECKSUM_NONE;
-   break;
-   } else {
-   struct sk_buff *free_it = next;
-
-   /* Old fragment is completely overridden with
-* new one drop it.
-*/
-   next = next->next;
-
-   if (prev)
-   prev->next = next;
-   else
-   qp->q.fragments = next;
-
-   qp->q.meat -= free_it->len;
-   sub_frag_mem_limit(qp->q.net, free_it->truesize);
-   kfree_skb(free_it);
-   }
-   }
+   /* Is there an overlap with the next fragment? */
+   if (next && next->ip_defrag_offset < end)
+   goto discard_qp;
 

[linux-yocto] [PATCH v4.18 00/10] Collection of mainline backports for CVEs

[Paul Gortmaker]

Bruce, yocto kernel folks,

Here is a group of mainline backports to our v4.18 standard/base that
address the following CVE items from this year:

CVE-2018-5391
CVE-2018-13096
CVE-2018-13097
CVE-2018-14610
CVE-2018-14611
CVE-2018-14612
CVE-2018-14613

I've applied them onto our standard/base at 2ba9a28434f8 and then built
and booted a defconfig + BTRFS + F2FS.  Also tested btrfs on a small
partition since the commits were about 1/2 for that alone.

Please apply and merge out to the respective branches when you have
a chance.

Thanks,
Paul.
---

Chao Yu (2):
  f2fs: fix to do sanity check with user_block_count
  f2fs: fix to do sanity check with node footer and iblocks

Gu Jinxiang (1):
  btrfs: validate type when reading a chunk

Peter Oskolkov (3):
  ip: discard IPv4 datagrams with overlapping segments.
  net: modify skb_rbtree_purge to return the truesize of all purged skbs.
  ip: use rb trees for IP frag queue.

Qu Wenruo (4):
  btrfs: Check that each block group has corresponding chunk at mount time
  btrfs: Verify that every chunk has corresponding block group at mount time
  btrfs: Introduce mount time chunk <-> dev extent mapping check
  btrfs: tree-checker: Verify block_group_item

 fs/btrfs/disk-io.c  |   7 +
 fs/btrfs/extent-tree.c  |  86 +++-
 fs/btrfs/tree-checker.c | 100 +
 fs/btrfs/volumes.c  | 214 +++-
 fs/btrfs/volumes.h  |   4 +
 fs/f2fs/inode.c |  25 +++-
 fs/f2fs/super.c |  13 +-
 include/linux/skbuff.h  |  11 +-
 include/net/inet_frag.h |   3 +-
 include/uapi/linux/snmp.h   |   1 +
 net/core/skbuff.c   |   6 +-
 net/ipv4/inet_fragment.c|  16 ++-
 net/ipv4/ip_fragment.c  | 239 +++-
 net/ipv4/proc.c |   1 +
 net/ipv6/netfilter/nf_conntrack_reasm.c |   1 +
 net/ipv6/reassembly.c   |   1 +
 16 files changed, 582 insertions(+), 146 deletions(-)

-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 02/10] f2fs: fix to do sanity check with node footer and iblocks

[Paul Gortmaker]

tel sysfillrect sysimgblt 
fb_sys_fops ttm drm aes_x86_64 crypto_simd cryptd 8139cp glue_helper mii 
pata_acpi floppy
[  556.529276] ---[ end trace 4ce02f25ff7d3df5 ]---
[  556.530340] RIP: 0010:f2fs_truncate_inode_blocks+0x4a7/0x6f0
[  556.531513] Code: e8 ae ea ff ff 41 89 c7 c1 e8 1f 84 c0 74 0a 41 83 ff fe 
0f 85 35 ff ff ff 81 85 b0 fe ff ff fb 03 00 00 e9 f7 fd ff ff 0f 0b <0f> 0b e8 
62 b7 9a 00 48 8b bd a0 fe ff ff e8 56 54 ae ff 48 8b b5
[  556.535330] RSP: 0018:8801f292f808 EFLAGS: 00010286
[  556.536395] RAX: ed003e73242d RBX: 8801f292f958 RCX: b88b81bc
[  556.537824] RDX:  RSI: 0004 RDI: 8801f3992164
[  556.539290] RBP: 8801f292f980 R08: ed003e73242d R09: ed003e73242d
[  556.540709] R10: 0001 R11: ed003e73242c R12: fc64
[  556.542131] R13: 8801f3992000 R14: 0058 R15: 8801
[  556.543579] FS:  7f8029297840() GS:8801f6f0() 
knlGS:
[  556.545180] CS:  0010 DS:  ES:  CR0: 80050033
[  556.546338] CR2: 55f5f57305d8 CR3: 0001f18b CR4: 06e0
[  556.547809] 
==
[  556.549248] BUG: KASAN: stack-out-of-bounds in arch_tlb_gather_mmu+0x52/0x170
[  556.550672] Write of size 8 at addr 8801f292fd10 by task umount/1310

[  556.552338] CPU: 1 PID: 1310 Comm: umount Tainted: G  D   
4.18.0-rc1+ #4
[  556.553886] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Ubuntu-1.8.2-1ubuntu1 04/01/2014
[  556.555756] Call Trace:
[  556.556264]  dump_stack+0x7b/0xb5
[  556.556944]  print_address_description+0x70/0x290
[  556.557903]  kasan_report+0x291/0x390
[  556.558649]  ? arch_tlb_gather_mmu+0x52/0x170
[  556.559537]  __asan_store8+0x57/0x90
[  556.560268]  arch_tlb_gather_mmu+0x52/0x170
[  556.561110]  tlb_gather_mmu+0x12/0x40
[  556.561862]  exit_mmap+0x123/0x2a0
[  556.562555]  ? __ia32_sys_munmap+0x50/0x50
[  556.563384]  ? exit_aio+0x98/0x230
[  556.564079]  ? __x32_compat_sys_io_submit+0x260/0x260
[  556.565099]  ? taskstats_exit+0x1f4/0x640
[  556.565925]  ? kasan_check_read+0x11/0x20
[  556.566739]  ? mm_update_next_owner+0x322/0x380
[  556.567652]  mmput+0x8b/0x1d0
[  556.568260]  do_exit+0x43a/0x1390
[  556.568937]  ? mm_update_next_owner+0x380/0x380
[  556.569855]  ? deactivate_super+0x5e/0x80
[  556.570668]  ? cleanup_mnt+0x61/0xa0
[  556.571395]  ? __cleanup_mnt+0x12/0x20
[  556.572156]  ? task_work_run+0xc8/0xf0
[  556.572917]  ? exit_to_usermode_loop+0x125/0x130
[  556.573861]  rewind_stack_do_exit+0x17/0x20
[  556.574707] RIP: 0033:0x7f8028b77487
[  556.575428] Code: Bad RIP value.
[  556.576106] RSP: 002b:7fff9f2e3598 EFLAGS: 0246 ORIG_RAX: 
00a6
[  556.577599] RAX:  RBX: 00ebd030 RCX: 7f8028b77487
[  556.579020] RDX: 0001 RSI:  RDI: 00ec41e0
[  556.580422] RBP: 00ec41e0 R08:  R09: 0014
[  556.581833] R10: 06b2 R11: 0246 R12: 7f802908083c
[  556.583252] R13:  R14: 00ebd210 R15: 7fff9f2e3820

[  556.584983] The buggy address belongs to the page:
[  556.585961] page:ea0007ca4bc0 count:0 mapcount:0 
mapping: index:0x0
[  556.587540] flags: 0x200()
[  556.588296] raw: 0200  dead0200 

[  556.589822] raw:    

[  556.591359] page dumped because: kasan: bad access detected

[  556.592786] Memory state around the buggy address:
[  556.593753]  8801f292fc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[  556.595191]  8801f292fc80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 
00
[  556.596613] >8801f292fd00: 00 00 f3 00 00 00 00 f3 f3 00 00 00 00 f4 f4 
f4
[  556.598044]  ^
[  556.598797]  8801f292fd80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 
00
[  556.600225]  8801f292fe00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 f4 f4 
f4
[  556.601647] 
==

- Location
https://elixir.bootlin.com/linux/v4.18-rc1/source/fs/f2fs/node.c#L987
case NODE_DIND_BLOCK:
err = truncate_nodes(, nofs, offset[1], 3);
cont = 0;
break;

default:
BUG(); <---
}

Reported-by Wen Xu 
Signed-off-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Paul Gortmaker 
---
 fs/f2fs/inode.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
index cf0f944fcaea..75a85b3341a3 100644
--- a/fs/f2fs/inode.c
+++ b/fs/f2fs/inode.c
@@ -185,9 +185,30 @@ void f2fs_inode_chksum_set(struct f2fs_sb_info *sbi, 
struct pag

[linux-yocto] [PATCH 01/10] f2fs: fix to do sanity check with user_block_count

[Paul Gortmaker]

.195644] raw: 0200  dead0200 

[  564.197247] raw:    

[  564.198826] page dumped because: kasan: bad access detected

[  564.200299] Memory state around the buggy address:
[  564.201306]  8801f3117b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[  564.202779]  8801f3117c00: 00 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 
f3
[  564.204252] >8801f3117c80: f3 f3 f3 00 00 00 00 00 00 00 00 00 f1 f1 f1 
f1
[  564.205742]^
[  564.206424]  8801f3117d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00
[  564.207908]  8801f3117d80: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 
00
[  564.209389] 
==
[  564.231795] F2FS-fs (loop0): Mounted with checkpoint version = 2

- Location
https://elixir.bootlin.com/linux/v4.18-rc1/source/fs/f2fs/segment.h#L586
return div_u64((u64)valid_user_blocks(sbi) * 100,
sbi->user_block_count);
Missing checks on sbi->user_block_count.

Reported-by: Wen Xu 
Signed-off-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
Signed-off-by: Paul Gortmaker 
---
 fs/f2fs/super.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 742147cbe759..c592ed30471d 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -2285,6 +2285,8 @@ int f2fs_sanity_check_ckpt(struct f2fs_sb_info *sbi)
unsigned int sit_segs, nat_segs;
unsigned int sit_bitmap_size, nat_bitmap_size;
unsigned int log_blocks_per_seg;
+   unsigned int segment_count_main;
+   block_t user_block_count;
int i;
 
total = le32_to_cpu(raw_super->segment_count);
@@ -2309,6 +2311,16 @@ int f2fs_sanity_check_ckpt(struct f2fs_sb_info *sbi)
return 1;
}
 
+   user_block_count = le64_to_cpu(ckpt->user_block_count);
+   segment_count_main = le32_to_cpu(raw_super->segment_count_main);
+   log_blocks_per_seg = le32_to_cpu(raw_super->log_blocks_per_seg);
+   if (!user_block_count || user_block_count >=
+   segment_count_main << log_blocks_per_seg) {
+   f2fs_msg(sbi->sb, KERN_ERR,
+   "Wrong user_block_count: %u", user_block_count);
+   return 1;
+   }
+
main_segs = le32_to_cpu(raw_super->segment_count_main);
blocks_per_seg = sbi->blocks_per_seg;
 
@@ -2325,7 +2337,6 @@ int f2fs_sanity_check_ckpt(struct f2fs_sb_info *sbi)
 
sit_bitmap_size = le32_to_cpu(ckpt->sit_ver_bitmap_bytesize);
nat_bitmap_size = le32_to_cpu(ckpt->nat_ver_bitmap_bytesize);
-   log_blocks_per_seg = le32_to_cpu(raw_super->log_blocks_per_seg);
 
if (sit_bitmap_size != ((sit_segs / 2) << log_blocks_per_seg) / 8 ||
nat_bitmap_size != ((nat_segs / 2) << log_blocks_per_seg) / 8) {
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 1/5] kthread: convert worker lock to raw spinlock

[Paul Gortmaker]

From: Julia Cartwright 

commit 5c8919eed1cfcad5da452047bd4ab088837afc41 in linux-rt-devel.

In order to enable the queuing of kthread work items from hardirq
context even when PREEMPT_RT_FULL is enabled, convert the worker
spin_lock to a raw_spin_lock.

This is only acceptable to do because the work performed under the lock
is well-bounded and minimal.

Cc: Sebastian Andrzej Siewior 
Cc: Guenter Roeck 
Reported-and-tested-by: Steffen Trumtrar 
Reported-by: Tim Sander 
Signed-off-by: Julia Cartwright 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 include/linux/kthread.h |  2 +-
 kernel/kthread.c| 42 +-
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index c1961761311d..ad292898f7f2 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -85,7 +85,7 @@ enum {
 
 struct kthread_worker {
unsigned intflags;
-   spinlock_t  lock;
+   raw_spinlock_t  lock;
struct list_headwork_list;
struct list_headdelayed_work_list;
struct task_struct  *task;
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 486dedbd9af5..c1d9ee6671c6 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -597,7 +597,7 @@ void __kthread_init_worker(struct kthread_worker *worker,
struct lock_class_key *key)
 {
memset(worker, 0, sizeof(struct kthread_worker));
-   spin_lock_init(>lock);
+   raw_spin_lock_init(>lock);
lockdep_set_class_and_name(>lock, key, name);
INIT_LIST_HEAD(>work_list);
INIT_LIST_HEAD(>delayed_work_list);
@@ -639,21 +639,21 @@ int kthread_worker_fn(void *worker_ptr)
 
if (kthread_should_stop()) {
__set_current_state(TASK_RUNNING);
-   spin_lock_irq(>lock);
+   raw_spin_lock_irq(>lock);
worker->task = NULL;
-   spin_unlock_irq(>lock);
+   raw_spin_unlock_irq(>lock);
return 0;
}
 
work = NULL;
-   spin_lock_irq(>lock);
+   raw_spin_lock_irq(>lock);
if (!list_empty(>work_list)) {
work = list_first_entry(>work_list,
struct kthread_work, node);
list_del_init(>node);
}
worker->current_work = work;
-   spin_unlock_irq(>lock);
+   raw_spin_unlock_irq(>lock);
 
if (work) {
__set_current_state(TASK_RUNNING);
@@ -810,12 +810,12 @@ bool kthread_queue_work(struct kthread_worker *worker,
bool ret = false;
unsigned long flags;
 
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
if (!queuing_blocked(worker, work)) {
kthread_insert_work(worker, work, >work_list);
ret = true;
}
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
return ret;
 }
 EXPORT_SYMBOL_GPL(kthread_queue_work);
@@ -841,7 +841,7 @@ void kthread_delayed_work_timer_fn(struct timer_list *t)
if (WARN_ON_ONCE(!worker))
return;
 
-   spin_lock(>lock);
+   raw_spin_lock(>lock);
/* Work must not be used with >1 worker, see kthread_queue_work(). */
WARN_ON_ONCE(work->worker != worker);
 
@@ -850,7 +850,7 @@ void kthread_delayed_work_timer_fn(struct timer_list *t)
list_del_init(>node);
kthread_insert_work(worker, work, >work_list);
 
-   spin_unlock(>lock);
+   raw_spin_unlock(>lock);
 }
 EXPORT_SYMBOL(kthread_delayed_work_timer_fn);
 
@@ -906,14 +906,14 @@ bool kthread_queue_delayed_work(struct kthread_worker 
*worker,
unsigned long flags;
bool ret = false;
 
-   spin_lock_irqsave(>lock, flags);
+   raw_spin_lock_irqsave(>lock, flags);
 
if (!queuing_blocked(worker, work)) {
__kthread_queue_delayed_work(worker, dwork, delay);
ret = true;
}
 
-   spin_unlock_irqrestore(>lock, flags);
+   raw_spin_unlock_irqrestore(>lock, flags);
return ret;
 }
 EXPORT_SYMBOL_GPL(kthread_queue_delayed_work);
@@ -949,7 +949,7 @@ void kthread_flush_work(struct kthread_work *work)
if (!worker)
return;
 
-   spin_lock_irq(>lock);
+   raw_spin_lock_irq(>lock);
/* Work must not be used with >1 worker, see kthread_queue_work(). */
WARN_ON_ONCE(work->worker != worker);
 
@@ -961,7 +961,7 @@ void kthread_flush_work(struct kthread_work *work)
else
noop = true;
 
-   spin_unlock_irq(>lock);
+   raw_spin_unlock_irq(>lock);
 
if (!noop)
wait_for_completion();
@@ -994,9 +994,9 @@ static bool __kthread_cancel

[linux-yocto] [PATCH 5/5] rt: update localversion to match latest content

[Paul Gortmaker]

In collection with these most recent changes:

   git log --oneline HEAD ^v4.18.7-rt5 ^v4.18.16
   a5a06f994ee0 (HEAD -> linux-4.18.y-rt, tag: v4.18.16-rt8, 
origin/linux-4.18.y-rt) v4.18.16-rt8
   206f5532c3c7 Merge tag 'v4.18.16' into linux-4.18.y-rt
   73dbed526d9b (tag: v4.18.12-rt7) v4.18.12-rt7
   c0f0dd3ced7a sched/migrate_disable: Add export_symbol_gpl for 
__migrate_disabled
   3260983a587d tty: serial: pl011: explicitly initialize the flags variable
   089cb35faad5 mm/kasan: make quarantine_lock a raw_spinlock_t
   e31a286f3889 watchdog: prevent deferral of watchdogd wakeup on RT
   5c8919eed1cf kthread: convert worker lock to raw spinlock
   5b0efb356a7b (tag: v4.18.12-rt6) v4.18.12-rt6
   986610231899 Merge tag 'v4.18.12' into linux-4.18.y-rt

Signed-off-by: Paul Gortmaker 
---
 localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/localversion-rt b/localversion-rt
index 0efe7ba1930e..700c857efd9b 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt5
+-rt8
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 3/5] mm/kasan: make quarantine_lock a raw_spinlock_t

[Paul Gortmaker]

From: Clark Williams 

commit 089cb35faad5da57fa90399b230b3aee4920bb02 in linux-rt-devel.

The static lock quarantine_lock is used in quarantine.c to protect the
quarantine queue datastructures. It is taken inside quarantine queue
manipulation routines (quarantine_put(), quarantine_reduce() and
quarantine_remove_cache()), with IRQs disabled.
This is not a problem on a stock kernel but is problematic on an RT
kernel where spin locks are sleeping spinlocks, which can sleep and can
not be acquired with disabled interrupts.

Convert the quarantine_lock to a raw spinlock_t. The usage of
quarantine_lock is confined to quarantine.c and the work performed while
the lock is held is limited.

Signed-off-by: Clark Williams 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 mm/kasan/quarantine.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/mm/kasan/quarantine.c b/mm/kasan/quarantine.c
index 3a8ddf8baf7d..b209dbaefde8 100644
--- a/mm/kasan/quarantine.c
+++ b/mm/kasan/quarantine.c
@@ -103,7 +103,7 @@ static int quarantine_head;
 static int quarantine_tail;
 /* Total size of all objects in global_quarantine across all batches. */
 static unsigned long quarantine_size;
-static DEFINE_SPINLOCK(quarantine_lock);
+static DEFINE_RAW_SPINLOCK(quarantine_lock);
 DEFINE_STATIC_SRCU(remove_cache_srcu);
 
 /* Maximum size of the global queue. */
@@ -190,7 +190,7 @@ void quarantine_put(struct kasan_free_meta *info, struct 
kmem_cache *cache)
if (unlikely(q->bytes > QUARANTINE_PERCPU_SIZE)) {
qlist_move_all(q, );
 
-   spin_lock(_lock);
+   raw_spin_lock(_lock);
WRITE_ONCE(quarantine_size, quarantine_size + temp.bytes);
qlist_move_all(, _quarantine[quarantine_tail]);
if (global_quarantine[quarantine_tail].bytes >=
@@ -203,7 +203,7 @@ void quarantine_put(struct kasan_free_meta *info, struct 
kmem_cache *cache)
if (new_tail != quarantine_head)
quarantine_tail = new_tail;
}
-   spin_unlock(_lock);
+   raw_spin_unlock(_lock);
}
 
local_irq_restore(flags);
@@ -230,7 +230,7 @@ void quarantine_reduce(void)
 * expected case).
 */
srcu_idx = srcu_read_lock(_cache_srcu);
-   spin_lock_irqsave(_lock, flags);
+   raw_spin_lock_irqsave(_lock, flags);
 
/*
 * Update quarantine size in case of hotplug. Allocate a fraction of
@@ -254,7 +254,7 @@ void quarantine_reduce(void)
quarantine_head = 0;
}
 
-   spin_unlock_irqrestore(_lock, flags);
+   raw_spin_unlock_irqrestore(_lock, flags);
 
qlist_free_all(_free, NULL);
srcu_read_unlock(_cache_srcu, srcu_idx);
@@ -310,17 +310,17 @@ void quarantine_remove_cache(struct kmem_cache *cache)
 */
on_each_cpu(per_cpu_remove_cache, cache, 1);
 
-   spin_lock_irqsave(_lock, flags);
+   raw_spin_lock_irqsave(_lock, flags);
for (i = 0; i < QUARANTINE_BATCHES; i++) {
if (qlist_empty(_quarantine[i]))
continue;
qlist_move_cache(_quarantine[i], _free, cache);
/* Scanning whole quarantine can take a while. */
-   spin_unlock_irqrestore(_lock, flags);
+   raw_spin_unlock_irqrestore(_lock, flags);
cond_resched();
-   spin_lock_irqsave(_lock, flags);
+   raw_spin_lock_irqsave(_lock, flags);
}
-   spin_unlock_irqrestore(_lock, flags);
+   raw_spin_unlock_irqrestore(_lock, flags);
 
qlist_free_all(_free, cache);
 
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 2/5] watchdog: prevent deferral of watchdogd wakeup on RT

[Paul Gortmaker]

From: Julia Cartwright 

commit e31a286f388949d4098ce0ddb27e2f558eb7fb18 in linux-rt-devel.

When PREEMPT_RT_FULL is enabled, all hrtimer expiry functions are
deferred for execution into the context of ktimersoftd unless otherwise
annotated.

Deferring the expiry of the hrtimer used by the watchdog core, however,
is a waste, as the callback does nothing but queue a kthread work item
and wakeup watchdogd.

It's worst then that, too: the deferral through ktimersoftd also means
that for correct behavior a user must adjust the scheduling parameters
of both watchdogd _and_ ktimersoftd, which is unnecessary and has other
side effects (like causing unrelated expiry functions to execute at
potentially elevated priority).

Instead, mark the hrtimer used by the watchdog core as being _HARD to
allow it's execution directly from hardirq context.  The work done in
this expiry function is well-bounded and minimal.

A user still must adjust the scheduling parameters of the watchdogd
to be correct w.r.t. their application needs.

Cc: Guenter Roeck 
Reported-and-tested-by: Steffen Trumtrar 
Reported-by: Tim Sander 
Signed-off-by: Julia Cartwright 
Acked-by: Guenter Roeck 
[bigeasy: use only HRTIMER_MODE_REL_HARD]
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/watchdog/watchdog_dev.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index ffbdc4642ea5..84f75b5045f6 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -147,7 +147,7 @@ static inline void watchdog_update_worker(struct 
watchdog_device *wdd)
ktime_t t = watchdog_next_keepalive(wdd);
 
if (t > 0)
-   hrtimer_start(_data->timer, t, HRTIMER_MODE_REL);
+   hrtimer_start(_data->timer, t, 
HRTIMER_MODE_REL_HARD);
} else {
hrtimer_cancel(_data->timer);
}
@@ -166,7 +166,7 @@ static int __watchdog_ping(struct watchdog_device *wdd)
if (ktime_after(earliest_keepalive, now)) {
hrtimer_start(_data->timer,
  ktime_sub(earliest_keepalive, now),
- HRTIMER_MODE_REL);
+ HRTIMER_MODE_REL_HARD);
return 0;
}
 
@@ -945,7 +945,7 @@ static int watchdog_cdev_register(struct watchdog_device 
*wdd, dev_t devno)
return -ENODEV;
 
kthread_init_work(_data->work, watchdog_ping_work);
-   hrtimer_init(_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+   hrtimer_init(_data->timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL_HARD);
wd_data->timer.function = watchdog_timer_expired;
 
if (wdd->id == 0) {
@@ -992,7 +992,7 @@ static int watchdog_cdev_register(struct watchdog_device 
*wdd, dev_t devno)
__module_get(wdd->ops->owner);
kref_get(_data->kref);
if (handle_boot_enabled)
-   hrtimer_start(_data->timer, 0, HRTIMER_MODE_REL);
+   hrtimer_start(_data->timer, 0, 
HRTIMER_MODE_REL_HARD);
else
pr_info("watchdog%d running and kernel based 
pre-userspace handler disabled\n",
wdd->id);
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 4/5] tty: serial: pl011: explicitly initialize the flags variable

[Paul Gortmaker]

From: Kurt Kanzenbach 

commit 3260983a587d528811a15fc00fa2a9e4473c4453 in linux-rt-devel.

Silence the following gcc warning:

drivers/tty/serial/amba-pl011.c: In function ‘pl011_console_write’:
./include/linux/spinlock.h:260:3: warning: ‘flags’ may be used uninitialized in 
this function [-Wmaybe-uninitialized]
   _raw_spin_unlock_irqrestore(lock, flags); \
   ^~~
drivers/tty/serial/amba-pl011.c:2214:16: note: ‘flags’ was declared here
  unsigned long flags;
^

The code is correct. Thus, initializing flags to zero doesn't change the
behavior and resolves the warning.

Signed-off-by: Kurt Kanzenbach 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/tty/serial/amba-pl011.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 484861278e9c..a658214486e7 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -2211,7 +2211,7 @@ pl011_console_write(struct console *co, const char *s, 
unsigned int count)
 {
struct uart_amba_port *uap = amba_ports[co->index];
unsigned int old_cr = 0, new_cr;
-   unsigned long flags;
+   unsigned long flags = 0;
int locked = 1;
 
clk_enable(uap->clk);
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 4.18-rt 0/5] Add most recent linux-rt-devel updates

[Paul Gortmaker]

Bruce, Yocto kernel folks.

Here are four commits found in the linux-rt-devel repository on the
4.18.x branch, plus the version bump to match that of the tag where
these commits can be found.

There is not a lot of updates but I did a quick sanity boot test
regardless, on top of:

   commit 8e00c30ce22f378ecb7f243b1df3d209b8ee29bc
   Merge: b5a193df148b 33859b3077c8
   Author: Bruce Ashfield 
   Date:   Mon Oct 15 09:53:05 2018 -0400

Merge branch 'v4.18/standard/base' into v4.18/standard/preempt-rt/base

The log of the version bump commit (#5) contains the surrounding commit
history from the linux-rt-devel repository.

Paul.
---

Clark Williams (1):
  mm/kasan: make quarantine_lock a raw_spinlock_t

Julia Cartwright (2):
  kthread: convert worker lock to raw spinlock
  watchdog: prevent deferral of watchdogd wakeup on RT

Kurt Kanzenbach (1):
  tty: serial: pl011: explicitly initialize the flags variable

Paul Gortmaker (1):
  rt: update localversion to match latest content

 drivers/tty/serial/amba-pl011.c |  2 +-
 drivers/watchdog/watchdog_dev.c |  8 
 include/linux/kthread.h |  2 +-
 kernel/kthread.c| 42 -
 localversion-rt |  2 +-
 mm/kasan/quarantine.c   | 18 +-
 6 files changed, 37 insertions(+), 37 deletions(-)

-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 09/10] work-simple: drop a shit statement in SWORK_EVENT_PENDING

[Paul Gortmaker]

From: Sebastian Andrzej Siewior 

commit 22f41ebe5579cc847a7bb6c71916be92c8926216 from linux-rt-devel.

Dan Carpenter reported
| smatch warnings:
|kernel/sched/swork.c:63 swork_kthread() warn: test_bit() takes a bit number

This is not a bug because we shift by zero (and use the same value in
both places).
Nevertheless I'm dropping that shift by zero to keep smatch quiet.

Cc: Daniel Wagner 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 kernel/sched/swork.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/swork.c b/kernel/sched/swork.c
index 1950f40ca725..5559c22f664c 100644
--- a/kernel/sched/swork.c
+++ b/kernel/sched/swork.c
@@ -12,7 +12,7 @@
 #include 
 #include 
 
-#define SWORK_EVENT_PENDING (1 << 0)
+#define SWORK_EVENT_PENDING 1
 
 static DEFINE_MUTEX(worker_mutex);
 static struct sworker *glob_worker;
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 08/10] rcu: Use cpus_read_lock() while looking at cpu_online_mask

[Paul Gortmaker]

From: Sebastian Andrzej Siewior 

commit eb1987eef4f20ae92c21c50c4c75c6148a27d482 from linux-rt-devel.

It was possible that sync_rcu_exp_select_cpus() enqueued something on
CPU0 while CPU0 was offline. Such a work item wouldn't be processed
until CPU0 gets back online. This problem was addressed in commit
fcc6354365015 ("rcu: Make expedited GPs handle CPU 0 being offline"). I
don't think the issue fully addressed.

Assume grplo = 0 and grphi = 7 and sync_rcu_exp_select_cpus() is invoked
on CPU1. The preempt_disable() section on CPU1 won't ensure that CPU0
remains online between looking at cpu_online_mask and invoking
queue_work_on() on CPU1.

Use cpus_read_lock() to ensure that `cpu' is not going down between
looking at cpu_online_mask at invoking queue_work_on() and waiting for
its completion. It is added around the loop + flush_work() which is
similar to work_on_cpu_safe() (and we can have multiple jobs running on
NUMA systems).

Fixes: fcc6354365015 ("rcu: Make expedited GPs handle CPU 0 being
  offline")
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 kernel/rcu/tree_exp.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/rcu/tree_exp.h b/kernel/rcu/tree_exp.h
index 01b6ddeb4f05..a104cf91e6b9 100644
--- a/kernel/rcu/tree_exp.h
+++ b/kernel/rcu/tree_exp.h
@@ -479,6 +479,7 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
sync_exp_reset_tree(rsp);
trace_rcu_exp_grace_period(rsp->name, rcu_exp_gp_seq_endval(rsp), 
TPS("select"));
 
+   cpus_read_lock();
/* Schedule work for each leaf rcu_node structure. */
rcu_for_each_leaf_node(rsp, rnp) {
rnp->exp_need_flush = false;
@@ -493,13 +494,11 @@ static void sync_rcu_exp_select_cpus(struct rcu_state 
*rsp,
continue;
}
INIT_WORK(>rew.rew_work, sync_rcu_exp_select_node_cpus);
-   preempt_disable();
cpu = cpumask_next(rnp->grplo - 1, cpu_online_mask);
/* If all offline, queue the work on an unbound CPU. */
if (unlikely(cpu > rnp->grphi))
cpu = WORK_CPU_UNBOUND;
queue_work_on(cpu, rcu_par_gp_wq, >rew.rew_work);
-   preempt_enable();
rnp->exp_need_flush = true;
}
 
@@ -507,6 +506,7 @@ static void sync_rcu_exp_select_cpus(struct rcu_state *rsp,
rcu_for_each_leaf_node(rsp, rnp)
if (rnp->exp_need_flush)
flush_work(>rew.rew_work);
+   cpus_read_unlock();
 }
 
 static void synchronize_sched_expedited_wait(struct rcu_state *rsp)
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 10/10] rt: bump localversion

[Paul Gortmaker]

We've added the equivalent updates from upstream in linux-rt-devel
as can be seen from this snippet of the commit history there:

  a7abcd43f6a7 (HEAD -> linux-4.18.y-rt, tag: v4.18.7-rt5, 
origin/linux-4.18.y-rt) v4.18.7-rt5
  22f41ebe5579 work-simple: drop a shit statement in SWORK_EVENT_PENDING
  eb1987eef4f2 rcu: Use cpus_read_lock() while looking at cpu_online_mask
  b75caf08b721 of: allocate / free phandle cache outside of the devtree_lock
  447cffcc7437 (tag: v4.18.7-rt4) v4.18.7-rt4
  a6dabcafaf68 Merge tag 'v4.18.7' into linux-4.18.y-rt
  ac0f534deae8 (tag: v4.18.5-rt3) v4.18.5-rt3
  b9fcc1867cc7 Drivers: hv: vmbus: include header for get_irq_regs()
  4a0819bb25d1 irqchip/gic-v3-its: Move pending table allocation to init time
  7bcb4eb241e3 powerpc: correct the preempt-lazy assembly
  3f1b0eab8fb3 staging: android: vsoc: use hrtimer_init_sleeper_on_stack()
  cd4d35ef8994 sched: Allow pinned user tasks to be awakened to the CPU they 
pinned
  5dd69ed1a24a (tag: v4.18.5-rt2) v4.18.5-rt2
  223076af168b Merge tag 'v4.18.5' into linux-4.18.y-rt
  ce25bc4adeb5 (tag: v4.18-rc8-rt1-rebase, tag: v4.18-rc8-rt1) Add localversion 
for -RT release

So bump the localversion to match.

Signed-off-by: Paul Gortmaker 
---
 localversion-rt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/localversion-rt b/localversion-rt
index 6f206be67cd2..0efe7ba1930e 100644
--- a/localversion-rt
+++ b/localversion-rt
@@ -1 +1 @@
--rt1
+-rt5
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 04/10] irqchip/gic-v3-its: Move pending table allocation to init time

[Paul Gortmaker]

From: Marc Zyngier 

commit 4a0819bb25d12d39c0390636122eefba232596c1 from linux-rt-devel.

Signed-off-by: Marc Zyngier 
[bigeasy: backport commit effe377d415 ("irqchip/gic-v3-its: Move pending
  table allocation to init time")]
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/irqchip/irq-gic-v3-its.c   | 94 +++---
 include/linux/irqchip/arm-gic-v3.h |  1 +
 2 files changed, 49 insertions(+), 46 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 4bca2439ee7d..907e5c5169e9 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1556,7 +1556,7 @@ static void its_free_prop_table(struct page *prop_page)
   get_order(LPI_PROPBASE_SZ));
 }
 
-static int __init its_alloc_lpi_tables(void)
+static int __init its_alloc_lpi_prop_table(void)
 {
phys_addr_t paddr;
 
@@ -1854,17 +1854,15 @@ static int its_alloc_collections(struct its_node *its)
return 0;
 }
 
-static struct page *its_allocate_pending_table(unsigned int cpu)
+static struct page *its_allocate_pending_table(gfp_t gfp_flags)
 {
struct page *pend_page;
-   unsigned int order;
/*
 * The pending pages have to be at least 64kB aligned,
 * hence the 'max(LPI_PENDBASE_SZ, SZ_64K)' below.
 */
-   order = get_order(max_t(u32, LPI_PENDBASE_SZ, SZ_64K));
-   pend_page = alloc_pages_node(cpu_to_node(cpu), GFP_KERNEL | __GFP_ZERO,
-order);
+   pend_page = alloc_pages(gfp_flags | __GFP_ZERO,
+   get_order(max_t(u32, LPI_PENDBASE_SZ, SZ_64K)));
if (!pend_page)
return NULL;
 
@@ -1880,25 +1878,31 @@ static void its_free_pending_table(struct page *pt)
   get_order(max_t(u32, LPI_PENDBASE_SZ, SZ_64K)));
 }
 
-static int its_alloc_pend_page(unsigned int cpu)
+static int __init allocate_lpi_tables(void)
 {
-   struct page *pend_page;
-   phys_addr_t paddr;
+   int err, cpu;
 
-   pend_page = gic_data_rdist_cpu(cpu)->pend_page;
-   if (pend_page)
-   return 0;
+   err = its_alloc_lpi_prop_table();
+   if (err)
+   return err;
 
-   pend_page = its_allocate_pending_table(cpu);
-   if (!pend_page) {
-   pr_err("Failed to allocate PENDBASE for CPU%d\n",
-  smp_processor_id());
-   return -ENOMEM;
+   /*
+* We allocate all the pending tables anyway, as we may have a
+* mix of RDs that have had LPIs enabled, and some that
+* don't. We'll free the unused ones as each CPU comes online.
+*/
+   for_each_possible_cpu(cpu) {
+   struct page *pend_page;
+
+   pend_page = its_allocate_pending_table(GFP_NOWAIT);
+   if (!pend_page) {
+   pr_err("Failed to allocate PENDBASE for CPU%d\n", cpu);
+   return -ENOMEM;
+   }
+
+   gic_data_rdist_cpu(cpu)->pend_page = pend_page;
}
 
-   paddr = page_to_phys(pend_page);
-   pr_info("CPU%d: using LPI pending table @%pa\n", cpu, );
-   gic_data_rdist_cpu(cpu)->pend_page = pend_page;
return 0;
 }
 
@@ -1906,13 +1910,15 @@ static void its_cpu_init_lpis(void)
 {
void __iomem *rbase = gic_data_rdist_rd_base();
struct page *pend_page;
+   phys_addr_t paddr;
u64 val, tmp;
 
-   /* If we didn't allocate the pending table yet, do it now */
-   pend_page = gic_data_rdist()->pend_page;
-   if (!pend_page)
+   if (gic_data_rdist()->lpi_enabled)
return;
 
+   pend_page = gic_data_rdist()->pend_page;
+   paddr = page_to_phys(pend_page);
+
/* set PROPBASE */
val = (page_to_phys(gic_rdists->prop_page) |
   GICR_PROPBASER_InnerShareable |
@@ -1964,6 +1970,10 @@ static void its_cpu_init_lpis(void)
 
/* Make sure the GIC has seen the above */
dsb(sy);
+   gic_data_rdist()->lpi_enabled = true;
+   pr_info("GICv3: CPU%d: using LPI pending table @%pa\n",
+   smp_processor_id(),
+   );
 }
 
 static void its_cpu_init_collection(struct its_node *its)
@@ -2744,7 +2754,7 @@ static int its_vpe_init(struct its_vpe *vpe)
return vpe_id;
 
/* Allocate VPT */
-   vpt_page = its_allocate_pending_table(raw_smp_processor_id());
+   vpt_page = its_allocate_pending_table(GFP_KERNEL);
if (!vpt_page) {
its_vpe_id_free(vpe_id);
return -ENOMEM;
@@ -3439,16 +3449,6 @@ static int redist_disable_lpis(void)
u64 timeout = USEC_PER_SEC;
u64 val;
 
-   /*
-* If coming via a CPU hotplug event, we don't need to disable
-* LPIs before trying to re-enable them. T

[linux-yocto] [PATCH 03/10] powerpc: correct the preempt-lazy assembly

[Paul Gortmaker]

From: Sebastian Andrzej Siewior 

commit 7bcb4eb241e37d111cbca61a86ea0da180a6f2b3 from linux-rt-devel.

The powerpc port won't compile and abort with "Error: operand out of
range" because the TIF_NEED_RESCHED_LAZY uses bit 20 which is larger
than 15 which is the upper limit.
Swap it with TIF_32BIT and fixup the assembly in one assembly file to
get it to compile again.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 arch/powerpc/include/asm/thread_info.h | 4 ++--
 arch/powerpc/kernel/entry_64.S | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/include/asm/thread_info.h 
b/arch/powerpc/include/asm/thread_info.h
index 431759836861..15c2c0925b6c 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -82,7 +82,7 @@ extern int arch_dup_task_struct(struct task_struct *dst, 
struct task_struct *src
 #define TIF_SIGPENDING 1   /* signal pending */
 #define TIF_NEED_RESCHED   2   /* rescheduling necessary */
 #define TIF_FSCHECK3   /* Check FS is USER_DS on return */
-#define TIF_32BIT  4   /* 32 bit binary */
+#define TIF_NEED_RESCHED_LAZY  4   /* lazy rescheduling necessary */
 #define TIF_RESTORE_TM 5   /* need to restore TM FP/VEC/VSX */
 #define TIF_PATCH_PENDING  6   /* pending live patching update */
 #define TIF_SYSCALL_AUDIT  7   /* syscall auditing active */
@@ -101,7 +101,7 @@ extern int arch_dup_task_struct(struct task_struct *dst, 
struct task_struct *src
 #define TIF_ELF2ABI18  /* function descriptors must die! */
 #endif
 #define TIF_POLLING_NRFLAG 19  /* true if poll_idle() is polling 
TIF_NEED_RESCHED */
-#define TIF_NEED_RESCHED_LAZY  20   /* lazy rescheduling necessary */
+#define TIF_32BIT  20  /* 32 bit binary */
 
 /* as above, but as bit values */
 #define _TIF_SYSCALL_TRACE (1<https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 06/10] of: allocate / free phandle cache outside of the devtree_lock

[Paul Gortmaker]

From: Sebastian Andrzej Siewior 

commit b75caf08b721aee6f0aec7350b2136ff1e704337 from linux-rt-devel.

The phandle cache code allocates memory while holding devtree_lock which
is a raw_spinlock_t. Memory allocation (and free()) is not possible on
RT while a raw_spinlock_t is held.
Invoke the kfree() and kcalloc() while the lock is dropped.

Cc: Rob Herring 
Cc: Frank Rowand 
Cc: devicet...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/of/base.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/drivers/of/base.c b/drivers/of/base.c
index 466e3c8582f0..7394d9dcc2a1 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -108,43 +108,49 @@ void of_populate_phandle_cache(void)
u32 cache_entries;
struct device_node *np;
u32 phandles = 0;
+   struct device_node **shadow;
 
raw_spin_lock_irqsave(_lock, flags);
-
-   kfree(phandle_cache);
+   shadow = phandle_cache;
phandle_cache = NULL;
 
for_each_of_allnodes(np)
if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL)
phandles++;
 
+   raw_spin_unlock_irqrestore(_lock, flags);
+
cache_entries = roundup_pow_of_two(phandles);
phandle_cache_mask = cache_entries - 1;
 
-   phandle_cache = kcalloc(cache_entries, sizeof(*phandle_cache),
-   GFP_ATOMIC);
-   if (!phandle_cache)
-   goto out;
+   kfree(shadow);
+   shadow = kcalloc(cache_entries, sizeof(*phandle_cache), GFP_KERNEL);
+
+   if (!shadow)
+   return;
+   raw_spin_lock_irqsave(_lock, flags);
+   phandle_cache = shadow;
 
for_each_of_allnodes(np)
if (np->phandle && np->phandle != OF_PHANDLE_ILLEGAL)
phandle_cache[np->phandle & phandle_cache_mask] = np;
 
-out:
raw_spin_unlock_irqrestore(_lock, flags);
 }
 
 int of_free_phandle_cache(void)
 {
unsigned long flags;
+   struct device_node **shadow;
 
raw_spin_lock_irqsave(_lock, flags);
 
-   kfree(phandle_cache);
+   shadow = phandle_cache;
phandle_cache = NULL;
 
raw_spin_unlock_irqrestore(_lock, flags);
 
+   kfree(shadow);
return 0;
 }
 #if !defined(CONFIG_MODULES)
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 05/10] Drivers: hv: vmbus: include header for get_irq_regs()

[Paul Gortmaker]

From: Sebastian Andrzej Siewior 

commit b9fcc1867cc7921bb8441be327ed58461ed12255 from linux-rt-devel.

On !RT the header file get_irq_regs() gets pulled in via other header files. On
RT it does not and the build fails:

drivers/hv/vmbus_drv.c:975 implicit declaration of function ‘get_irq_regs’ 
[-Werror=implicit-function-declaration]
drivers/hv/hv.c:115 implicit declaration of function ‘get_irq_regs’ 
[-Werror=implicit-function-declaration]

Add the header file for get_irq_regs() in a common header so it used by
vmbus_drv.c by hv.c for their get_irq_regs() usage.

Reported-by: Bernhard Landauer 
Reported-by: Ralf Ramsauer 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/hv/hyperv_vmbus.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
index 72eaba3d50fc..797f07918197 100644
--- a/drivers/hv/hyperv_vmbus.h
+++ b/drivers/hv/hyperv_vmbus.h
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "hv_trace.h"
 
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 02/10] staging: android: vsoc: use hrtimer_init_sleeper_on_stack()

[Paul Gortmaker]

From: Sebastian Andrzej Siewior 

commit 3f1b0eab8fb3d592ae2da62a62b0522b365781e0 from linux-rt-devel.

This is an update to v2 of "hrtimer: consolidate hrtimer_init() +
hrtimer_init_sleeper() calls" which also converts
hrtimer_init_on_stack() + hrtimer_init_sleeper() in the vsoc.c driver.

Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 drivers/staging/android/vsoc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/android/vsoc.c b/drivers/staging/android/vsoc.c
index 806beda1040b..6c7f666c0e33 100644
--- a/drivers/staging/android/vsoc.c
+++ b/drivers/staging/android/vsoc.c
@@ -438,12 +438,10 @@ static int handle_vsoc_cond_wait(struct file *filp, 
struct vsoc_cond_wait *arg)
 
if (!timespec_valid())
return -EINVAL;
-   hrtimer_init_on_stack(>timer, CLOCK_MONOTONIC,
- HRTIMER_MODE_ABS);
+   hrtimer_init_sleeper_on_stack(to, CLOCK_MONOTONIC,
+ HRTIMER_MODE_ABS, current);
hrtimer_set_expires_range_ns(>timer, timespec_to_ktime(ts),
 current->timer_slack_ns);
-
-   hrtimer_init_sleeper(to, current);
}
 
while (1) {
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 4.18-rt 00/10] upstream updates rt1 --> rt5

[Paul Gortmaker]

Bruce, Yocto kernel folks,

Here are the preempt-rt updates applied to the 4.18 yocto kernel.
A couple of the version bumps were just merges of the latest stable
tag from GregKH, and no preempt-rt specific changes.  The details
of the updates that did have -rt specific content are listed below:

rt3: https://marc.info/?l=linux-rt-users=153561780819025=2

rt5: https://marc.info/?l=linux-rt-users=153665816630557=2

These patches were applied onto the current Yocto 4.18 preempt-rt
base branch and sanity boot tested on x86-64 defconfig + RT_FULL.

One RCU patch is from mainline directly, and also found backported
in newer 4.18.x stable tags than we are currently running, as it
was a prerequisite for the RCU change in the preempt-rt updates.

Paul.
---

Boqun Feng (1):
  rcu: Make expedited GPs handle CPU 0 being offline

Marc Zyngier (1):
  irqchip/gic-v3-its: Move pending table allocation to init time

Mike Galbraith (1):
  sched: Allow pinned user tasks to be awakened to the CPU they pinned

Paul Gortmaker (1):
  rt: bump localversion

Sebastian Andrzej Siewior (6):
  staging: android: vsoc: use hrtimer_init_sleeper_on_stack()
  powerpc: correct the preempt-lazy assembly
  Drivers: hv: vmbus: include header for get_irq_regs()
  of: allocate / free phandle cache outside of the devtree_lock
  rcu: Use cpus_read_lock() while looking at cpu_online_mask
  work-simple: drop a shit statement in SWORK_EVENT_PENDING

 arch/powerpc/include/asm/thread_info.h |  4 +-
 arch/powerpc/kernel/entry_64.S |  2 +-
 drivers/hv/hyperv_vmbus.h  |  1 +
 drivers/irqchip/irq-gic-v3-its.c   | 94 +-
 drivers/of/base.c  | 22 +---
 drivers/staging/android/vsoc.c |  6 +--
 include/linux/irqchip/arm-gic-v3.h |  1 +
 kernel/rcu/tree_exp.h  |  9 +++-
 kernel/sched/core.c|  2 +-
 kernel/sched/swork.c   |  2 +-
 localversion-rt|  2 +-
 11 files changed, 80 insertions(+), 65 deletions(-)

-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 01/10] sched: Allow pinned user tasks to be awakened to the CPU they pinned

[Paul Gortmaker]

From: Mike Galbraith 

commit cd4d35ef89948221f7cd1751cee453943967364c from linux-rt-devel.

Since commit 7af443ee16976 ("sched/core: Require cpu_active() in
select_task_rq(), for user tasks") select_fallback_rq() will BUG() if
the CPU to which a task has pinned itself and pinned becomes
!cpu_active() while it slept.
The task will continue running on the to-be-removed CPU and will remove
itself from the CPU during takedown_cpu() (while cpuhp_pin_lock will be
acquired) and move to another CPU based on its mask after the
migrate_disable() section has been left.

Cc: stable...@vger.kernel.org
Signed-off-by: Mike Galbraith 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: Paul Gortmaker 
---
 kernel/sched/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 530118fbfe21..7d789c1b316b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -968,7 +968,7 @@ static inline bool is_cpu_allowed(struct task_struct *p, 
int cpu)
if (!cpumask_test_cpu(cpu, p->cpus_ptr))
return false;
 
-   if (is_per_cpu_kthread(p))
+   if (is_per_cpu_kthread(p) || __migrate_disabled(p))
return cpu_online(cpu);
 
return cpu_active(cpu);
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.29

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the final 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.28 kernel.

After months of warning, hopefully it comes as no surprise to anyone
that this is the last 4.12.x release.

There are about 100 commits here, based on commits chosen from what
was used in existing 4.14.x stable releases.

The 4.14 versions I was auditing contained batch updates from DaveM in
the networking department, and hence that is represented significantly
here in these commits.

I've also jumped ahead and looked at what arm64 did in 4.14-stable for
the whole ssbd stuff, and did my best to drag that back kicking and
screaming to 4.12.

I've put this 4.12.x queue through the usual testing that I figured made
sense, which is in line with that listed explicitly in previous release
announcements.

Given the footprint of the ARM64/KVM changes for ssbd, I did an ARM64
allyesconfig and build tested that.  But to be clear, sanity boot
testing ARM64 guests is beyond what I have time/resources for.

Thank you all for making use of this kernel version.  It is nice to know
the work in backports gets used.  But the time has come to re-direct my
focus onto work for newer kernel versions.  I hope you can all move to a
newer version as well.

I did the signed tag just as per the previously released 4.12.x versions.

Please find a signed v4.12.29 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.12.x release.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.28

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.27 kernel.

Hopefully people using 4.12.x have their plans well underway to move to
a newer kernel, as I have been indicating for several releases now that
my maintenance work on 4.12.x is coming to a close.  There will probably
be one more release in roughly two weeks, assuming we don't encounter
any high profile CVE issues in the interim.

There are just over 80 commits here, based on commits chosen from what
was used in existing 4.14.x stable releases.

I've put this 4.12.x queue through the usual testing that I figured made
sense, which is in line with that listed explicitly in previous release
announcements.

I did the signed tag just as per the previously released 4.12.x versions.

Please find a signed v4.12.28 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.12.x release.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.27

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.26 kernel.

Hopefully people using 4.12.x are already getting their plans in place
to moving to a newer kernel in the near future, as the number of
additional 4.12.x releases that I do will probably be limited to a
couple more over the next month or so.

This is the second release in a row with the normal "one issue -- one
commit" type of stable content, which is nice.  There are about 125
commits here, based on commits chosen from what was used in existing
4.14.x stable releases.

I've put this 4.12.x queue through the usual testing that I figured made
sense, which is in line with that listed explicitly in previous release
announcements.

I did the signed tag just as per the previously released 4.12.x versions.

Please find a signed v4.12.27 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.12.x release.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.26

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.25 kernel.

And a reminder: people using 4.12.x should be getting their plans in
place to moving to a newer kernel in the near future, as the number of
additional 4.12.x releases that I do will be limited to a few more
over the next couple months.  

With the previous release being all about spectre, and all the commits
largely inter-dependent on each other,  I figured I'd jump right back in
and try and get some of the normal "one issue -- one commit" type of
stable content in place.  To that end, there are about 125 commits here,
based on commits chosen for the 4.14.x stable release, and then suitably
filtered based on applicability to our 4.12.x baseline used here.

I've put this 4.12.x queue through the usual testing that I figured made
sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.12.x versions.

Please find a signed v4.12.26 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the raw commits that were used to create this 4.12.x
release.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.25

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.24 kernel.

This is also a good time to note that people using 4.12.x should be
getting their plans in place to moving to a newer kernel in the near
future, as the number of additional 4.12.x releases that I do will be
limited to a couple more over the next several months.  

Unfortunately, after only two releases with what were "normal" single
issue commits for stable releases, we are back to what is largely a
whole release aimed at a single issue.  There are close to 70 commits
here, and they are all related to spectre/speculative-store-bypass (SSB)
or dependency commits paving the road to using those SSB commits.

Also unfortunate, is that once again, these changes are in core low
level files, mixed with assembly, and not just one line simple
"stable" fixes.  A look at the top "winners" in the diffstat shows:

 arch/x86/kernel/cpu/bugs.c | 369 +++--
 arch/x86/entry/calling.h   | 104 +++---
 arch/x86/entry/entry_64.S  |  91 ++---
 arch/x86/kernel/cpu/common.c   |  78 -
 arch/x86/include/asm/nospec-branch.h   |  54 ++-
 include/linux/nospec.h |  46 ++-
 arch/x86/include/asm/spec-ctrl.h   |  40 +++
 arch/x86/entry/entry_64_compat.S   |  30 ++

In an ideal world I'd rather not see any changes to these types of files
in "stable" content, but it seems our hands are tied.

The selection of commits is largely from those that appeared from two
mainline merges, in 4.16 and 4.17 respectively.  For those who want more
details, please consult the series file in the queue repository listed
at the end of this message to see the ID prefix of those merges and
their individual commit content.

Given that the focus is largely on SSB, a few notes are in order.
Firstly, the backports in this release give the key new status file:

   /sys/devices/system/cpu/vulnerabilities/spec_store_bypass

which is specific to the new SSB changes announced in late May. It is
too much to get into here on the details, so folks should start with the
file Documentation/userspace-api/spec_ctrl.rst and the new boot-args
related to spec_store_bypass_disable added to the existing file in
Documentation/admin-guide/kernel-parameters.txt -- from there, folks
should have enough keywords to do effective online searches for more
specific details.

As this is a two part solution (kernel and microcode), testing was done
on an older xeon v2 (circa 2014 firmware) and a very recent laptop with
a firmware update only weeks old.

The xeon with patches but old firmware -- /sys status file reported:
  Vulnerable

The modern laptop with latest BIOS/firmware/microcode reported:
  Mitigation: Speculative Store Bypass disabled via prctl and seccomp

If you don't see the status file at all, you've not booted a kernel with
the SSB patches applied.

In addition to the SSB specifics, I've put this 4.12.x queue through the
usual testing that I figured made sense, which includes but is not
limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

Given the content was 99% x86, the non-x86 builds were probably a waste
of time, but a routine is a routine...

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.12.x versions.

Please find a signed v4.12.25 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the raw commits that were used to create this 4.12.x
release.  As mentioned above, the series file in release/v4.12.25 has
information relating to the commits used in this release.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.24

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.23 kernel.

There are about 90 commits here, and for the 2nd release in a row, we
are with no real multi-commit topics, meaning things are remaining as
what people expect to be normal for a stable release.  Again it is
selected content based on what was used for 4.14-stable that would also
be appropriate for the 4.12 kernel here.

As usual, I've put this 4.12.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.12.x versions.

Please find a signed v4.12.24 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the raw commits that were used to create this 4.12.x
release, similar to Greg's stable queue with the 4.14.x content
mentioned above:

   https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.23

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.22 kernel.

There about 150 commits here, with no real multi-commit topics, meaning
things are returning to what is normal for a stable release.  It is
just a few CVEs that I was made aware of, plus selected content
based on what was used for 4.14-stable that would also be appropriate
for the 4.12 kernel here.

As usual, I've put this 4.12.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.12.x versions.

Please find a signed v4.12.23 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the raw commits that were used to create this 4.12.x
release, similar to Greg's stable queue:

   https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.22

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.21 kernel.

There about 125 commits here, with the main thing being addition of the
ARM/64 mainline retpoline commits based on what was used for 4.14-stable.
The next biggest thing was a tracing update that was implicitly required
after the x86 ktpi/retpoline changes.  And there were some additional
mainline commits added to cover the gap between 4.12 and the 4.14.

Since just like x86, these recent largely pulicised security issues also
end up making changes to the low level ARM code, I boot tested both ARM
and ARM64 - standard and preempt-rt variants under qemu.

As usual, I've put this 4.12.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig
-test x86-64 with preempt-rt patches.
-test arm/arm64 with and without preempt-rt patches

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.12.x versions.

Please find a signed v4.12.22 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the raw commits that were used to create this 4.12.x
release, similar to Greg's stable queue:

   https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.21

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.20 kernel.

There about 90 commits here, with the main thing being addition of the
mainline retpoline commits based on what was used for 4.14-stable.
There is also now the /sys/devices/system/cpu/vulnerabilities dir that
I suspect people will be looking for.

As usual, I've put this 4.12.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig
-test x86-64 with preempt-rt patches.

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.12.x versions.

Please find a signed v4.12.21 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the raw commits that were used to create this 4.12.x
release, similar to Greg's stable queue:

   https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.28

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is a quick 4.8.x stable update. There are only about 10 patches
here as this release is primarily to set the stage for better
compatibility with the existing preempt-rt content in Yocto.

To that end, I've tested it with the Yocto kernel-cache preempt-rt
patches applied, and I've also done test merges of it to standard/base
and standard/preempt-rt/base.  As the merge to -rt required some
manual intervention, I'll provide you with those test merges out of
band for your reference while you are updating linux-yocto-4.8

As usual, I've put this 4.8.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig
-build and boot test merge of this with -rt in Yocto.

I bumped the Makefile and did the signed tag just as per the previously
released 4.8.x versions.

Please find a signed v4.8.28 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the raw commits can be found here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for reference.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.27

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.8.x stable update.  Continuing on top of the
previously released v4.8.26 kernel, we now have content selected from
the 4.9.x series to address some of the high profile CVEs that have
garnered a lot of attention this year.

One departure of note, is that in the past, I have used other nearby
releases as a reference for content we might want to consider, but then
always re-exported the commits directly from mainline, to ensure that I
get to see all conflicts and similar 1st hand.

However, the 4.9.x stable tree (and it seems all older backports) are
early adopters of the KAISER patch set:

https://lwn.net/Articles/738975/

...which to be sure, influenced what eventually went into mainline,
however there is no 1:1 mapping between the KAISER patches and mainline.
As such, there really isn't much choice but to use the 4.9.x versions of
the KAISER patches, since having worked on mainline backports for the
4.12 version, I know trying to take them back to 4.9 would not be the
right choice here.

One thing this shares with the 4.12 release is the much more complex
interdependency between the commits and the baseline they are designed
for.  So, just like 4.12, I have backported select commits from 4.9 in
order to facilitate using the 4.9 versions of the stable commits largely
as-is, in the interest of having the most stable end result.

As usual, I've put this 4.8.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I also got some local assistance in running specific tests related to
the CVEs, which was greatly appreciated.

I bumped the Makefile and did the signed tag just as per the previously
released 4.8.x versions.

Please find a signed v4.8.27 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the raw commits can be found here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; but one thing that might be of
interest is to inspect the series file, since it is self documenting in
terms of what patches were 4.9 backports of mainline and what came from
the 4.9 stable queue directly, and hence can be used as a quick summary
guide of what was addressed with this release.

I suspect we will need to do another 4.8.x release to cover off similar
issues on non-x86 architecture targets.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.20

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.19 kernel.

As hinted at in the previous release, there was a desire to clear the
queue of the stand-alone fixes to make room for more complicated
changes we have here.

And so here we have a queue of patches that, unlike previous stable
commits, has a much more complex interdependency, versus the stand alone
commits we are used to seeing in stable releases of the past.

As much as I would like to not make changes to core files that aren't
strictly bug fixes, it was necessary in order to bring back the mainline
commits related to recent security concerns.  So we have more commits
here in this round that don't have the normal "Fixes: " we
are used to.

Expanding the sphere to include patches which were dependencies of the
patches we wanted for KPTI seemed to be the right choice from a
stability point of view, versus smashing a square peg into a round hole,
even if it drove the patch count higher than I would have liked.

That said, we have a 4.12.x that contains 100% mainline commits.
Keeping to the original stable goal of not using any commits that did
not go mainline.  Having done this, I can appreciate the challenge, and
how people on older releases have decided to use earlier "Kaiser"
snapshots even though none of those commits ever were merged to mainline.

As usual, I've put this 4.12.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.12.x versions.

Please find a signed v4.12.20 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the raw commits that were used to create this 4.12.x
release, similar to Greg's stable queue:

   https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/

One thing which is new for this release, is that the series file does now 
contain annotations which show the chronological progression of the
commits in mainline, since that was instrumental in trying to get this
release right.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 2/2] hrtimer: Update offset for soft bases

[Paul Gortmaker]

From: Anna-Maria Gleixner <anna-ma...@linutronix.de>

The offset of the clock bases is done via timekeeping mechanisms. The
offsets of the soft bases has to be considered as well.

Signed-off-by: Anna-Maria Gleixner <anna-ma...@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bige...@linutronix.de>
Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com>
---
 kernel/time/hrtimer.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index fd26eade86a3..db396eafc774 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -562,8 +562,14 @@ static inline ktime_t hrtimer_update_base(struct 
hrtimer_cpu_base *base)
ktime_t *offs_boot = >clock_base[HRTIMER_BASE_BOOTTIME].offset;
ktime_t *offs_tai = >clock_base[HRTIMER_BASE_TAI].offset;
 
-   return ktime_get_update_offsets_now(>clock_was_set_seq,
+   ktime_t now = ktime_get_update_offsets_now(>clock_was_set_seq,
offs_real, offs_boot, offs_tai);
+
+   base->clock_base[HRTIMER_BASE_REALTIME_SOFT].offset = *offs_real;
+   base->clock_base[HRTIMER_BASE_BOOTTIME_SOFT].offset = *offs_boot;
+   base->clock_base[HRTIMER_BASE_TAI_SOFT].offset = *offs_tai;
+
+   return now;
 }
 
 /*
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 1/2] lockdep: disable self-test

[Paul Gortmaker]

From: Sebastian Andrzej Siewior <bige...@linutronix.de>

The self-test wasn't always 100% accurate for RT. We disabled a few
tests which failed because they had a different semantic for RT. Some
still reported false positives. Now the selftest locks up the system
during boot and it needs to be investigated…

Signed-off-by: Sebastian Andrzej Siewior <bige...@linutronix.de>
Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com>
---
 lib/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 1f1cb51005de..cc977b9189bb 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1163,7 +1163,7 @@ config DEBUG_ATOMIC_SLEEP
 
 config DEBUG_LOCKING_API_SELFTESTS
bool "Locking API boot-time self-tests"
-   depends on DEBUG_KERNEL
+   depends on DEBUG_KERNEL && !PREEMPT_RT_FULL
help
  Say Y here if you want the kernel to run a short self-test during
  bootup. The self-test checks whether common types of locking bugs
-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 4.12-rt 0/2] Two small fixes for rt/base on yocto-4.12

[Paul Gortmaker]

Two small fixlets for real world issues on standard/preempt-rt/base in
the linux-yocto-4.12 repository:

The 1st fixes an issue where the LTP testcase timerfd01 failed.

The second resolves a known issue where AUFS causes false positives
of a lockdep fail by claiming there are not enough classes.

Applied to standard/preempt-rt/base of today, and built for defconfig
with RT_FULL enabled, and booted on a COTS Core2 Duo machine.

Paul.
---

Anna-Maria Gleixner (1):
  hrtimer: Update offset for soft bases

Sebastian Andrzej Siewior (1):
  lockdep: disable self-test

 kernel/time/hrtimer.c | 8 +++-
 lib/Kconfig.debug | 2 +-
 2 files changed, 8 insertions(+), 2 deletions(-)

-- 
2.15.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.19

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the 5th 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.18 kernel.

As indicated in the previous release, the 4.13 source that was being
used as a reference for commits we'd want here has been depleted.

So in this case, I've selected some commits in mainline that are found
to be used in the 4.14.x releases, plus some commits that are specific
to various CVE issues.

Note that there is only about 65 commits here.  These are all single
stand-alone commits that each solve one issue.  I thought it would be
good to "clear the plate" so to speak, and draw a line in the sand
before putting more complex fixes that span multiple commits into the
queue for the next 4.12.x release.

As usual, I've put this 4.12.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.12.x versions.

Please find a signed v4.12.19 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the raw commits that were used to create this 4.12.x
release, similar to Greg's stable queue:

   https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PULL REQUEST] Intel Axxia updates to linux-yocto-4.12

[Paul Gortmaker]

[Re: [linux-yocto] [PULL REQUEST] Intel Axxia updates to linux-yocto-4.12] On 
23/01/2018 (Tue 15:57) Dragomir Daniel wrote:

> 
> On 20.01.2018 04:18, Paul Gortmaker wrote:
> >[[linux-yocto] [PULL REQUEST] Intel Axxia updates to linux-yocto-4.12] On 
> >18/01/2018 (Thu 20:03) Daniel Dragomir wrote:
> >
> >>Hello Bruce!
> >>
> >>This is the first pull request for Axxia changes on kernel 4.12 which were
> >>ported from our 4.9 Yocto branches.
> >>I checked all the patches with checkpatch.pl script and fixed all errors.
> >>Also, I compiled Axxia BSP using both branches and successfully booted the
> >>Victoria (arm64) board.
> >>
> >>Please pull the patches from
> >>https://github.com/axxia/axxia_yocto_linux_4.12_pull.git
> >>into
> >>git://git.yoctoproject.org/linux-yocto-4.12
> >>
> >>Pull
> >>standard/axxia/base-1.1 -> standard/axxia/base
> >>standard/preempt-rt/axxia/base-1.1 -> standard/preempt-rt/axxia/base
> >Hi Daniel,
> >
> >I don't normally look at BSP specifics, but I could not help seeing
> >changes in the diffstat that were **way** outside of what would qualify
> >as board specific.   For example:
> >
> >  init/main.c
> >  kernel/irq/manage.c
> >
> >show up in the diffstat.  To be clear these are just two examples and I
> >am not looking for specific answers to why those 2 changes exist.  The
> >bigger problem is why this board strays so far outside of the "normal"
> >board specific dirs, like boot, and dts and arch/arm/mach-*
> >
> >This kind of thing is not new; we have seen decades of vendor specific
> >SDK kernel changes that are not board specific and simply not anything
> >that would ever have a hope of getting merged to mainline.  Any chance
> >we can clean up the footprint of this thing to be more board specific?
> >
> >Thanks,
> >Paul
> >--
> 
> Hi Paul!
> 
> Thanks for your reply.
> This series patches is a porting from 4.9 and there are some old patches
> which are the problem here.
> We'll try a clean up and resend a v2 series.

Sounds good; you can probably work off two basic premises by looking at
the diffstat of each patch in a scripted fashion.

1) Are files being patched in any way ARM specific?  No - delete patch.
This means no patches to top level fs/ dir or top level mm/ dir, no
fiddling with existing locking primitives and so forth.

2) Now you are left with ARM files.  Your question now becomes "Is this
ARM file in any way board/BSP specific?"  Acceptable files would be
hooking into a Kconfig and Makefile.  Hopefully there should be no need
for a BSP to be trying to patch files in arch/arm64/kernel/ though.

THanks,
Paul.
--

> 
> Best regards,
> Daniel
> 
> >>If you add more patches to standard/(preempt-rt)/axxia/base beforehand
> >>please notify me. I will rebase our changes so you can do a clean,
> >>fast-forward pull.
> >>
> >>Thank you,
> >>Daniel Dragomir
> >>
> >>Anders Berg (14):
> >>   arm64: dts: Add initial AXM56xx device tree
> >>   arm64: Add Axxia NEMAC Gigabit Ethernet controller
> >>   arm64: dts: Corrected SPI definitions for AXM56xx
> >>   arm64: dts: Added SPI and flash for AXM56xx sim
> >>   arm64: dts: Add VMFS node for simulation DT
> >>   net: ethernet: Enable Axxia FEMAC driver
> >>   arm64: dts: Add device tree for AXC67xx (Lionfish)
> >>   arm64: dts: Fixed bad VMFS reg property
> >>   net: ethernet: Add MDIO driver for LSI AXM55xx
> >>   net: ethernet: Add driver for FEMAC on AXM55xx
> >>   drivers: net: Add Axxia NEMAC driver
> >>   arm64: dts: Add NEMAC device nodes
> >>   net: nemac: Fix crash when using NEMAC from bootloader
> >>   misc: lsi-ncr: Only use AMP lock on PPC platforms.
> >>
> >>Charlie Paul (51):
> >>   i2c: Support for i2c to the LSI axxia 5500 board
> >>   fs/vmfs: Added VMFS support to Axxia BSP
> >>   drivers/dma: Updated to support Axxia dma
> >>   arch/arm/boot/dts: Files added to support axxia 5500 board
> >>   arch/arm/boot: Changes to support the axxia BSP
> >>   arch/arm/mach-axxia: kernel files to support the mach-axxia
> >>   arch/arm: arm changes to support the axxia BSP
> >>   misc: Changes made to support axxia BSP
> >>   drivers/mtd: Changes to support the axxia BSP
> >>   drivers/net/ethernet: Changes to support the axxia BSP
> >>   drivers/rapidio/devices: Changes to support axxia BSP
> >>   drivers/spi: Changes to support the axxia BSP
&

Re: [linux-yocto] [PULL REQUEST] Intel Axxia updates to linux-yocto-4.12

[Paul Gortmaker]

[[linux-yocto] [PULL REQUEST] Intel Axxia updates to linux-yocto-4.12] On 
18/01/2018 (Thu 20:03) Daniel Dragomir wrote:

> Hello Bruce!
> 
> This is the first pull request for Axxia changes on kernel 4.12 which were
> ported from our 4.9 Yocto branches.
> I checked all the patches with checkpatch.pl script and fixed all errors.
> Also, I compiled Axxia BSP using both branches and successfully booted the
> Victoria (arm64) board.
> 
> Please pull the patches from
> https://github.com/axxia/axxia_yocto_linux_4.12_pull.git
> into
> git://git.yoctoproject.org/linux-yocto-4.12
> 
> Pull
> standard/axxia/base-1.1 -> standard/axxia/base
> standard/preempt-rt/axxia/base-1.1 -> standard/preempt-rt/axxia/base

Hi Daniel,

I don't normally look at BSP specifics, but I could not help seeing
changes in the diffstat that were **way** outside of what would qualify
as board specific.   For example:

 init/main.c 
 kernel/irq/manage.c   

show up in the diffstat.  To be clear these are just two examples and I
am not looking for specific answers to why those 2 changes exist.  The
bigger problem is why this board strays so far outside of the "normal"
board specific dirs, like boot, and dts and arch/arm/mach-*

This kind of thing is not new; we have seen decades of vendor specific
SDK kernel changes that are not board specific and simply not anything
that would ever have a hope of getting merged to mainline.  Any chance
we can clean up the footprint of this thing to be more board specific?

Thanks,
Paul
--

> 
> If you add more patches to standard/(preempt-rt)/axxia/base beforehand
> please notify me. I will rebase our changes so you can do a clean,
> fast-forward pull.
> 
> Thank you,
> Daniel Dragomir
> 
> Anders Berg (14):
>   arm64: dts: Add initial AXM56xx device tree
>   arm64: Add Axxia NEMAC Gigabit Ethernet controller
>   arm64: dts: Corrected SPI definitions for AXM56xx
>   arm64: dts: Added SPI and flash for AXM56xx sim
>   arm64: dts: Add VMFS node for simulation DT
>   net: ethernet: Enable Axxia FEMAC driver
>   arm64: dts: Add device tree for AXC67xx (Lionfish)
>   arm64: dts: Fixed bad VMFS reg property
>   net: ethernet: Add MDIO driver for LSI AXM55xx
>   net: ethernet: Add driver for FEMAC on AXM55xx
>   drivers: net: Add Axxia NEMAC driver
>   arm64: dts: Add NEMAC device nodes
>   net: nemac: Fix crash when using NEMAC from bootloader
>   misc: lsi-ncr: Only use AMP lock on PPC platforms.
> 
> Charlie Paul (51):
>   i2c: Support for i2c to the LSI axxia 5500 board
>   fs/vmfs: Added VMFS support to Axxia BSP
>   drivers/dma: Updated to support Axxia dma
>   arch/arm/boot/dts: Files added to support axxia 5500 board
>   arch/arm/boot: Changes to support the axxia BSP
>   arch/arm/mach-axxia: kernel files to support the mach-axxia
>   arch/arm: arm changes to support the axxia BSP
>   misc: Changes made to support axxia BSP
>   drivers/mtd: Changes to support the axxia BSP
>   drivers/net/ethernet: Changes to support the axxia BSP
>   drivers/rapidio/devices: Changes to support axxia BSP
>   drivers/spi: Changes to support the axxia BSP
>   drivers/hwmon: Changes made to support the axxia BSP
>   drivers/tty: Changes to support the axxia BSP
>   drivers/usb/host: Changes to support the axxia BSP
>   fs/vmfs: Changes to add VMFS support for axxia.
>   arch/arm/mach-axxia: Removed axxia_circular_queue
>   arch/arm/mach-axxia: fixed compiler warning
>   arch/arm/mach-axxia: fixed NO SMP
>   arch/arm/mach-axxia: changed affinity parameter to cpu
>   arch/arm/mach-axxia: Reverse checkpatch compatibility
>   arch/arm/mach-axxia: Fixed L2 power up failure
>   hwmon: Remove adt75 redundant driver
>   arch/arm/axxia: Remove the axxia zImage.fm build
>   fs/vmfs: Altered to allow vmfs to compile
>   drivers/ethernet/lsi: Fixed code to support 4.1
>   arm/mach-axxia: Updated to support linux 4.1
>   drivers/misc: Updated to support linux 4.1
>   fs/vmfs: Updated code to support linux 4.1
>   arm64: mm: Removed calls to reset_pmuserenr_el0
>   fs/vmfs: Updated to support the axxia on Linux 4.9
>   drivers/rapidio: Update to support linux 4.9
>   drivers/pci: updated to support axxia for 4.9
>   drivers/net: Updated to support axxia on 4.9
>   driver/net/ethernet: Updated to support axxia on 4.9
>   drivers/misc: Updated to support axxia on 4.9
>   drivers/i2c/busses: Updated to support axxia on 4.9
>   arch/arm/mach-axxia: Updated to support 4.9 on the 5500
>   i2c/busses: Updated to support 4.9 on the 5500
>   drivers/net: Updated to support 4.9 on the 5500
>   boot/dts/axxia: Updated to support 4.9 on the 5500
>   arm/mach-axxia: allow interupts (16-32) set to LOW
>   drivers/usb/core: fix over-current race condition
>   drivers/usb/dwc3: Initialize dma for axxia dwc3
>   drivers/hwmon: adt75 removed for redundency
>   drivers/edac: Added axxia edac
>   fs/vmfs: Added vmfs
>   drivers/gpio: updated to support axxia gpio
>   drivers/net/ethernet: updated nemac for compile
>   drivers/usb/dwc3: updated to compile usb 

[linux-yocto] v4.12.x - stable updates comprising v4.12.18

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the 4th 4.12.x stable update "extension" primarily created for
the Yocto project.  Continuing on top of the previous v4.12.17 kernel,
we now have the appropriate content from 4.13.14 --> 4.13.16 (inclusive)
applied on top of where we left off previously.  It amounts to a little
over 90 commits once the stuff that isn't applicable to 4.12 is removed.

This release is smaller in size because it depletes the only remaining
4.13.x releases to be used as references for suitable content.  I will
have to look at the content of other releases in the new year it seems.

Perhaps of interest is that over 1/2 the commits added here are for
networking.  Which isn't real surprising when one knows that DaveM
creates the stable networking content and then hands it off to GregKH.

There are also a few commits that resulted from me doing an audit of all
"Fixes:" tags since v4.12 in mainline and cross referencing that to
commits we've added in doing these four releases.  Meaning we are
looking for fixes to the fixes.  This seems useful, so I'll keep doing
that as a sanity check on future releases.

As usual, I've put this 4.12.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.8.x versions for the older release.

Please find a signed v4.12.18 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.12.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH yocto 4.12] add UDP patch to fix DHCP regression

[Paul Gortmaker]

Bruce,

It turns out that unfortunately a fix found in 4.13.6 was overlooked
for addition to 4.12 because the "Fixes:" tag was newer than the
4.12 kernel.  However that doesn't allow for the fact that this fix
is a fix for a fix we backported to 4.12 already.  This is a corner
case I can script an audit for, going forward.

I have added it to the queue for the pending 4.12.18 release, but as
it actually causes breakage in real world use cases involving DHCP
and containers, would you please apply it across linux-yocto-4.12
now?  The copy that lands in 4.12.18 will be silenty and automatically
handled by git merge once I've released that tag for Yocto to use.

A big thanks to Jason Wessel who did the bisect to track this down
and apologies to anyone else who got impacted by this omission.

Thanks,
Paul.
---

Paolo Abeni (1):
  udp: fix bcast packet reception

 net/ipv4/udp.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

-- 
2.1.4

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.17

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the 3rd 4.12.x stable update "extension" primarily created for
the Yocto project.  Continuing on top of the previous v4.12.16 kernel,
we now have the appropriate content from 4.13.10 --> 4.13.13 (inclusive)
applied on top of where we left off previously.  It amounts to a little
over 160 commits once the stuff that isn't applicable to 4.12 is removed.

There are still 4.3.14 --> 4.3.16 releases to look at in terms of what
makes sense for 4.12.x --- and after that we'll need to look at tracking
other stable streams for suggestions of appropriate content for 4.12.x
since 4.13.16 has also gone EOL by the normal stable kernel team.

I also added a few commits at the end of the queue that were not in the
above 4.13.x range but address some CVE issues that were brought to my
attention.

As usual, I've put this 4.12.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.8.x versions for the older release.

Please find a signed v4.12.17 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.12.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] v4.12.x - stable updates comprising v4.12.15

[Paul Gortmaker]

[v4.12.x - stable updates comprising v4.12.15] On 26/11/2017 (Sun 02:49) Paul 
Gortmaker wrote:

> Bruce, Yocto kernel folks:
> 
> Here is the 1st 4.12.x stable update.  Continuing on top of the final
> Greg KH released v4.12.14 kernel, we now have the appropriate content
> from 4.13.4 --> 4.13.5 (inclusive) applied on top of the GregKH
> baseline. 
> 
> Since the last 4.12 release was done at the same time as 4.13.3, that is
> why auditing of 4.13.4+ content for appropriate 4.12.x commits was
> chosen as a starting point.  These combined 4.13.x releases result in
> just about 185 backported commits to the 4.12.x baseline we wish to
> extend maintenance on.

Since I was in the mindset of auditing and adding appropriate patches, I
continued to work through some more of the 4.13.x content.  So now we
have a 4.12.16, which is based on the appropriate content from the audit
of what was added into 4.13.6 to 4.13.9 inclusive, which also gives us
about 185 more stable commits for our 4.12.x baseline.

Everything below (testing, locations, signed tag) remains true for .16
just as it did for the earlier .15 release.  Feel free to merge both at
once if you have not merged .15 yet.

Paul.
--

> 
> As usual, I've put this 4.12.x queue through the various testing that I
> figured made sense, which includes but is not limited to:
> 
> -x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
> -build MIPS, PPC, ARM, ARM64 with defconfig
> -build x86-64 allmodconfig/allyesconfig
> -build i386 allmodconfig/allyesconfig
> 
> I bumped the 4.12 Makefile and did the signed tag just as per the previously
> released 4.8.x versions for the older release.
> 
> Please find a signed v4.12.15 tag using this key:
> 
> http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6
> 
> in the repo in my kernel.org directory here:
> 
>https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
>git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git
> 
> for merge to standard/base in linux-yocto-4.12 and then out from there
> into the other base and BSP branches.
> 
> For those who are interested, the evolution of the commits is here:
> 
>https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/
> 
> This repo isn't needed for anything; it just exists for transparency and
> so people can see how the commits were adjusted to apply to the 4.12.x
> kernel baseline in case people are interested.
> 
> Paul.
> --
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.15

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is the 1st 4.12.x stable update.  Continuing on top of the final
Greg KH released v4.12.14 kernel, we now have the appropriate content
from 4.13.4 --> 4.13.5 (inclusive) applied on top of the GregKH
baseline. 

Since the last 4.12 release was done at the same time as 4.13.3, that is
why auditing of 4.13.4+ content for appropriate 4.12.x commits was
chosen as a starting point.  These combined 4.13.x releases result in
just about 185 backported commits to the 4.12.x baseline we wish to
extend maintenance on.

As usual, I've put this 4.12.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the 4.12 Makefile and did the signed tag just as per the previously
released 4.8.x versions for the older release.

Please find a signed v4.12.15 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.12.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] Contribute meta-installer to yocto

[Paul Gortmaker]

On 2017-11-21 12:41 AM, Hongxu Jia wrote:
> Hi all,
> 
> Wind River has maintained meta-installer for several years,
> and now we want to contribute it to yocto community.
> 
> This layer provides an installation program based on
> OE platform. The installation program is anaconda from
> fedora, which is the installer of distribution Fedora,
> RedHat and Centos.

I think you have missed your target audience.  This list is for yocto specific 
kernel changes.  It is not for addition of new layers.

Paul.
--

> 
> The version of anaconda in meta-installer is 26.21.11
> which is based on Fedora 26.
> 
> The meta-insatller requires:
> - systemd as init manager
> - python3
> - dnf2/rpm4
> - gobject-introspection which requires qemu-usermode
>    in MACHINE_FEATURES
> 
> The meta-installer provides:
> - graphic install and text install.
> 
> - package based (dnf/rpm) install and image (copy)
>    based install.
> 
> - package based (dnf/rpm) install from local and
>    remote rpm sources such as CDs and DVDs, images
>    stored on a hard drive, NFS, HTTP, and FTP.
> 
> - kickstart install which provides a fully unattended
>    installation that can be duplicated on scores of machines.
> 
> - install over VNC on headless machines.
> 
> - timezone setting.
> 
> - root password setting.
> 
> - user account creation.
> 
> - a variety of advanced storage devices including
>    LVM, Btrfs, Ext4, and filesystem encryption.
> 
> The repository of meta-installer is temporary on the github
> for review:
> https://github.com/jiahongxujia/meta-installer
> 
> In above github, the logo picture is undefined, if yocto
> could accept this layer, I will update the picture with
> "Yocto project Compatible".
> 
> The attachments are the snapshots of a package based
> installation.
> 
> Hopefully it is helpful for yocto, and any feedback is
> appreciated.
> 
> If yocto is interested in this layer and will accept it,
> I could send pull request or some one directly fetch
> from above github master branch.
> 
> //Hongxu
> 
> 
> 

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.26

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.8.x stable update.  Continuing on top of the
previously released v4.8.25 kernel, we now have the appropriate content
from 4.9.25 --> 4.9.29 (inclusive) applied on top of the latest 4.8
baseline.  Once again, I've combined several 4.9.x which results in
just about 200 backported commits out of that original 4.9.x range.

As usual, I've put this 4.8.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with defconfig
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the Makefile and did the signed tag just as per the previously
released 4.8.x versions.

Please find a signed v4.8.26 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 4.12] edac: split scc into enablement and patching (for treegen)

[Paul Gortmaker]

Calling out the existing edac.scc via KERNEL_FEATURES_append will
fail since it contains patch commands, and the patches will
unconditionally be queued for application.  Split it so instead it
can use

   KERNEL_FEATURES_append += "features/edac/edac-enable.scc"

in templates/configuration files external to the kernel-cache.

Note that we also hook the remaining patch chunk into the standard
ktype so that "rebase" branches (when created) will faithfully
mirror the content merged into the fast forward branches.

Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com>

diff --git a/features/edac/edac-enable.scc b/features/edac/edac-enable.scc
new file mode 100644
index ..69b71a6a61a0
--- /dev/null
+++ b/features/edac/edac-enable.scc
@@ -0,0 +1,4 @@
+define KFEATURE_DESCRIPTION "Enable core EDAC functionality"
+define KFEATURE_COMPATIBILITY board
+
+kconf hardware edac.cfg
diff --git a/features/edac/edac.scc b/features/edac/edac.scc
index bc483189..58dc3ebf585e 100644
--- a/features/edac/edac.scc
+++ b/features/edac/edac.scc
@@ -1,7 +1,3 @@
-define KFEATURE_DESCRIPTION "Enable core EDAC functionality"
-define KFEATURE_COMPATIBILITY board
-   
-kconf hardware edac.cfg
 patch EDAC-pnd2-Return-proper-error-value-from-apl_rd_reg.patch
 patch EDAC-pnd2-Make-function-sbi_send-static.patch
 patch EDAC-pnd2-Fix-Apollo-Lake-DIMM-detection.patch
diff --git a/ktypes/standard/standard.scc b/ktypes/standard/standard.scc
index fb8b34382dfb..662d0cb1edb9 100644
--- a/ktypes/standard/standard.scc
+++ b/ktypes/standard/standard.scc
@@ -78,6 +78,7 @@ include features/uptime/uptime.scc
 include features/ktest/ktest.scc
 include features/perf/perf.scc
 include features/input/input.scc
+include features/edac/edac.scc
 
 include features/bfq.scc
 include backports/backports.scc
-- 
2.13.3

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

[Paul Gortmaker]

[Re: [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of 
__list_lru_init_key] On 28/09/2017 (Thu 10:37) Cal Sullivan wrote:

> 
> 
> On 09/28/2017 07:53 AM, Paul Gortmaker wrote:
> >[[linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of 
> >__list_lru_init_key] On 22/09/2017 (Fri 15:48) California Sullivan wrote:
> >
> >>__list_lru_init_key does not exist. We're looking for __list_lru_init as
> >>shown in the patch "26690f5 mm: workingset: fix premature shadow node
> >I don't have that commit ID in mainline.  I see this:
> That commit ID won't be in mainline - it was a backport patch to 4.8.

OK, in the future, please list the repo your ID reference is in.

> >
> >commit 0cefabdaf757a6455d75f00cb76874e62703ed18
> >Author: Johannes Weiner <han...@cmpxchg.org>
> >Date:   Fri Mar 31 15:11:52 2017 -0700
> >
> > mm: workingset: fix premature shadow node shrinking with cgroups
> >
> >Did you perhaps rebase or similar?  Since the patch below is identical
> >to the commit above, it is more appropriate to preserve the original
> >commit log and authorship, as per how nearly all stable backports are
> >handled.
> The patch isn't  quite identical: __list_lru_init_key vs list_lru_init_key.
> It somehow got mangled in the merge commit 7f56c636.

If I recall correctly this was one of the functions the rt folks put
leading underscores on, since they changed something about it and didn't
want any "old" call sites to leak through un-audited.  THat probably led
to the merge confusion.

P.
--

> 
> ---
> Cal
> 
> >
> >P.
> >--
> >
> >>shrinking with cgroups".
> >>
> >>Signed-off-by: California Sullivan <california.l.sulli...@intel.com>
> >>---
> >>
> >>This is for the standard/preempt-rt/base branch. Standard/base is OK.
> >>
> >>  mm/workingset.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >>diff --git a/mm/workingset.c b/mm/workingset.c
> >>index 1856fdb..5e953eb 100644
> >>--- a/mm/workingset.c
> >>+++ b/mm/workingset.c
> >>@@ -493,7 +493,7 @@ static int __init workingset_init(void)
> >>pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
> >>   timestamp_bits, max_order, bucket_order);
> >>-   ret = __list_lru_init_key(&__workingset_shadow_nodes, true, 
> >>_nodes_key);
> >>+   ret = __list_lru_init(&__workingset_shadow_nodes, true, 
> >>_nodes_key);
> >>if (ret)
> >>goto err;
> >>ret = register_shrinker(_shadow_shrinker);
> >>-- 
> >>2.9.5
> >>
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of __list_lru_init_key

[Paul Gortmaker]

[[linux-yocto-4.8][PATCH] mm/workingset.c: fix implicit declaration of 
__list_lru_init_key] On 22/09/2017 (Fri 15:48) California Sullivan wrote:

> __list_lru_init_key does not exist. We're looking for __list_lru_init as
> shown in the patch "26690f5 mm: workingset: fix premature shadow node

I don't have that commit ID in mainline.  I see this:

commit 0cefabdaf757a6455d75f00cb76874e62703ed18
Author: Johannes Weiner 
Date:   Fri Mar 31 15:11:52 2017 -0700

mm: workingset: fix premature shadow node shrinking with cgroups

Did you perhaps rebase or similar?  Since the patch below is identical
to the commit above, it is more appropriate to preserve the original
commit log and authorship, as per how nearly all stable backports are
handled.

P.
--

> shrinking with cgroups".
> 
> Signed-off-by: California Sullivan 
> ---
> 
> This is for the standard/preempt-rt/base branch. Standard/base is OK.
> 
>  mm/workingset.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/workingset.c b/mm/workingset.c
> index 1856fdb..5e953eb 100644
> --- a/mm/workingset.c
> +++ b/mm/workingset.c
> @@ -493,7 +493,7 @@ static int __init workingset_init(void)
>   pr_info("workingset: timestamp_bits=%d max_order=%d bucket_order=%u\n",
>  timestamp_bits, max_order, bucket_order);
>  
> - ret = __list_lru_init_key(&__workingset_shadow_nodes, true, 
> _nodes_key);
> + ret = __list_lru_init(&__workingset_shadow_nodes, true, 
> _nodes_key);
>   if (ret)
>   goto err;
>   ret = register_shrinker(_shadow_shrinker);
> -- 
> 2.9.5
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.25

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.8.x stable update.  Continuing on top of the
previously released v4.8.24 kernel, we now have the appropriate content
from 4.9.22 to 4.9.24 (inclusive) applied on top of our latest 4.8
baseline.  Once again, I've combined several 4.9.x which results in
just under 200 backported commits out of that original 4.9.x range.

Of note, it includes the stack/heap CVE fixes backported from the
4.9.x stable release which were outside of the above range, but they
seemed worthy of jumping ahead in the 4.9.x queue that remains.

As usual, I've put this 4.8.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test + workloads of defconfig on COTS Core2 box.
-build MIPS, PPC, ARM, ARM64 with yocto .config and toolchains
-build x86-64 allmodconfig/allyesconfig
-build i386 allmodconfig/allyesconfig

I bumped the Makefile and did the signed tag just as per the previously
released 4.8.x versions.

Please find a signed v4.8.24 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.24

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.8.x stable update.  Continuing on top of the
previously released v4.8.23 kernel, we now have the appropriate content
from 4.9.18 to 4.9.21 (inclusive) applied on top of our latest 4.8
baseline.  Once again, I've combined several 4.9.x which results in
about 150 backported commits out of the 200 found in that 4.9.x range.

As usual, I've put this 4.8.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test of defconfig on COTS Core2 i915 family box.
-build MIPS, PPC, ARM, ARM64 with yocto .config and toolchains
-build x86-64 allmodconfig/allyesconfig
-build i386 defconfig

I bumped the Makefile and did the signed tag just as per the previously
released 4.8.x versions.

Please find a signed v4.8.24 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.23

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is another 4.8.x stable update.  Continuing on top of the previously
released v4.8.22 kernel, we now have the appropriate content from 4.9.15
to 4.9.17 applied on top of our latest 4.8 baseline.  Once again, I've
combined several 4.9.x which results in about 165 backported commits out
of the 200 found in that 4.9.x range.

As before, I've put this 4.8.x queue through the various testing that I
figured made sense, which includes but is not limited to:

-x86-64 sanity boot test of defconfig on COTS Core2 i915 family box.
-build MIPS, PPC, ARM, ARM64 with yocto .config and toolchains
-build x86-64 allmodconfig/allyesconfig
-build i386 defconfig

I bumped the Makefile and did the signed tag just as per the previously
released 4.8.x versions.

Please find a signed v4.8.23 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH] base.cfg: Add POSIX_TIMERS to fix ping hang

[Paul Gortmaker]

On 2017-04-17 08:31 PM, Saul Wold wrote:
> busybox ping was hanging after 1 loop with 4.10.x/4.11.x kernel.
> ping was hanging waiting for alarm to expire.
> 4.10.x kernel intrdoduced new kernel config CONFIG_POSIX_TIMERS
> which needs to be enabled to enable calls timer_create, settimer,
> alarm etc.

This shouldn't be needed:

init/Kconfig:config POSIX_TIMERS
init/Kconfig:   bool "Posix Clocks & timers" if EXPERT
init/Kconfig:   default y

...so unless we've got a config frag explicitly setting it to
off, it should be selected/on.  Since you say it is a new option,
then we shouldn't have any frag setting it to off.

Paul.
--

> Signed-off-by: Kushwaha, Priyalee 
> Signed-off-by: Saul Wold 
> ---
> Targeted for 4.10 and beyond
> 
>  ktypes/base/base.cfg | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/ktypes/base/base.cfg b/ktypes/base/base.cfg
> index 91a140b..062f6e3 100644
> --- a/ktypes/base/base.cfg
> +++ b/ktypes/base/base.cfg
> @@ -23,6 +23,7 @@ CONFIG_LOCALVERSION=""
>  CONFIG_SWAP=y
>  CONFIG_SYSVIPC=y
>  CONFIG_POSIX_MQUEUE=y
> +CONFIG_POSIX_TIMERS=y
>  CONFIG_BSD_PROCESS_ACCT=y
>  CONFIG_BSD_PROCESS_ACCT_V3=y
>  # CONFIG_AUDIT is not set
> 
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[yocto] [meta-raspberrypi][PATCH] README: document 64 bit r-pi3 variant for MACHINE

[Paul Gortmaker]

Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com>
---
 README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README b/README
index 9fdd5eb523df..19c38c3a085a 100644
--- a/README
+++ b/README
@@ -80,6 +80,7 @@ c. Set MACHINE in local.conf to one of the supported boards:
 - raspberrypi0
 - raspberrypi2
 - raspberrypi3
+- raspberrypi3-64 (64 bit kernel & userspace)
 - raspberrypi-cm (dummy alias for raspberrypi)
 - raspberrypi-cm3 (dummy alias for raspberrypi2)
 d. bitbake rpi-hwup-image
-- 
2.7.4

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.22

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is yet another 4.8.x stable update.  Continuing on the previously
released v4.8.21 kernel, we now have the appropriate content from 4.9.12
to 4.9.14 applied on top of our latest 4.8 baseline.  Once again, I've
combined several 4.9.x which results in about 170 backported commits.

As before, I've put this 4.8.x queue through the various testing that I
figured made sense, and then bumped the Makefile and did the signed tag
just as per the previously released 4.8.x versions.

Please find a signed v4.8.22 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] hid-multitouch driver missing from 4.8.3

[Paul Gortmaker]

[[linux-yocto] hid-multitouch driver missing from 4.8.3] On 28/03/2017 (Tue 
16:13) Paul Knopf wrote:

> I am using meta-intel BSP's on a board that has a multitouch device, but it
> isn't working. I need hd-multitouch.c, specifically.
> 
> I checked the local kernel that was built, but didn't see the touch driver in
> there.
> 
> build/tmp/work/corei7-64-intel-common-poky-linux/linux-yocto/
> 4.8.3+gitAUTOINC+6d028d2818_1adf9d3633-r0/
> linux-corei7-64-intel-common-standard-build/drivers/hid/*

The kernel source is not in tmp/work but tmp/work-shared now.

I'm guessing you'll find you have the driver but not the Konfig setting
for it enabled in your final .config file.

Paul.
--

> 
> However, if I check the git repos directly, the driver is there.
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.8/tree/drivers/hid?id=
> v4.8.3
> 
> I am using Yocto 2.2, if that matters.

> -- 
> ___
> linux-yocto mailing list
> linux-yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.21

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Here is yet another 4.8.x stable update.  Continuing on the previously
released v4.8.20 kernel, we now have the appropriate content from 4.9.8
to 4.9.11 applied on top of our latest 4.8 baseline.  Once again, I've
combined several 4.9.x which results in about 150 backported commits.

As before, I've put this 4.8.x queue through the various testing that I
figured made sense, and then bumped the Makefile and did the signed tag
just as per the previously released 4.8.x versions.

Please find a signed v4.8.21 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.20

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Another week, another stable update.  Continuing on the previously
released v4.8.19 kernel, we now have the appropriate content from 4.9.6
and 4.9.7 applied on top of our latest 4.8 baseline.  Once again, I've
combined two 4.9.x which results in about 150 backported commits.

As before, I've put this 4.8.x queue through the various testing that I
figured made sense, and then bumped the Makefile and did the signed tag
just as per the v4.8.19 and v4.8.18 previously.

Please find a signed v4.8.20 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.8.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see how the commits were adjusted to apply to the 4.8.x
kernel baseline in case people are interested.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.19

[Paul Gortmaker]

Bruce, Yocto kernel folks:

Continuing on the previously released v4.8.18 kernel, we now have
the appropriate content from 4.9.4 and 4.9.5 applied on top of that.
I've combined the two since 4.9.4 alone only contributed about 50
changesets; adding in the appropriate 4.9.5 content gets us to about
the same quantity as the v4.8.18 release was.

I've put this 4.8.x queue through the various testing that I figured
made sense, and after no obvious problems, I bumped the Makefile and
did the signed tag just as per the v4.8.18 from a week or so ago.

Testing: Booted v4.8.19 on a COTS x86_64 Core2 Duo machine.  I've also
built v4.8.19 for mips, ppc, arm, arm64 in allmodconfig and by using
yocto-4.9 builds and then hard reset standard/base to v4.8.19; followed
by a rebuild for the arch specific yocto .config file. 

Please find a signed v4.8.19 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] v4.8.x - stable updates comprising v4.8.18

[Paul Gortmaker]

Bruce, Yocto kernel folks:

The current v4.8.17 baseline was released at the same time as v4.9.2
stable.  This means that we need to start looking at the v4.9.3 stable
content in terms of what makes sense for v4.8.x -- also since v4.9 was
completed well before v4.8.17 was done, we know we don't need to examine
the content between 4.8.0 and 4.9.0 for v4.8.x stable backports.

The v4.9.3 release brought in roughly 200 backports over what was in
v4.9.2 --- after auditing them and removing commits that were for 4.9+
and refresing the remaining commits as required, there were ~160 that
remained as applicable against the v4.8.17 baseline of interest here.

I've put this 4.8.x queue through all the testing that I figured
made sense, and after no obvious problems, I bumped the Makefile and
did the signed tag just as I've done in the past for the v2.6.34
"official" longterm kernel.org stable releases I'd created.  Unlike
the older 2.6.34 release, I'm not intending to push this back out
through Greg and into the main stable repos ; partly to minimize
overhead, and partly to allow me to end updates once it is no longer
relevant to Yocto releases.

Testing: Booted v4.8.18 ; booted v4.8.18 tag merged into yocto's
preempt-rt/base; both on a COTS x86_64 Core2 Duo machine.  I've also
built v4.8.18 for mips, ppc, arm, arm64 by using yocto-4.9 builds and
then hard reset standard/base to v4.8.18; followed by running a
"make oldconfig ; make -j20" in a devshell to rebuild the vmlinux
there and finally confirming via "strings" that the vmlinux were
indeed v4.8.18 and not v4.9.6

As it is tagged in the same way Greg did tag his updates, your
existing workflow should be unchanged, except now it has to source
a repo on kernel.org in my directory instead of Greg's:

Please find a signed v4.8.18 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in my kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.8.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.8.y.git

for merge to standard/base in linux-yocto-4.8 and then out from there
into the other base and BSP branches.  The test merges that I did
locally indicated no obvious signs of looming conflicts.

Paul.
--
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PULL] kernel-cache; yocto-4.6: stage latest -rt content

[Paul Gortmaker]

This pull achieves several things for the 4.6.x yocto kernel, listed
in dependency order, with #3 being the most relevant to folks:

   1) ensure kernel cache, when fed into yocto-kernel-tools,
  generates output that is source identical to existing
  base branches of git://git.yoctoproject.org/linux-yocto-4.6.git

   2) #1 sets the stage for adding /base-REBASE branches
  like the linux-stable-rt people have (CAPS optional) which
  will be source identical to their fast forward counterparts.

   3) import the latest -rt kernel content from the git devel repo
  of the rt folks on kernel.org, commit for commit, so we can 
  use it to create standard/preempt-rt/base on linux-yocto-4.6

I ensured the kernel-cache was consistent (see #1) and refreshed
accordingly before updating the kver to 4.6.1 (where the current
fast forward tree is) -- hence the two patch refresh commits.
While the patch refresh isn't strictly necessary, I feel better
knowing we are using "git am" for everything w/o using "patch".

The -rt folks are a couple stable releases ahead of us currently
but in order to maintain consistency between rt and the current
standard, I did not advance our [yocto] kver past 4.6.1 for now.
It doesn't seem to impact patch applicability any, so no rush.

The 4.6-rt commits currently live in linux-rt-devel on kernel.org
vs. the usual linux-stable-rt [where it will end up eventually].
So I took advantage of that to give us (yocto) a 1:1 mapping of
the updates on that repo as pseudo cherry picks (pseudo, because
of path prefix remappings, series --> rt.scc etc.)  So that is
the reason for the rather brief shortlogs on the -rt changes; I've
left them as-is per the upstream repo from which they came.

The resulting standard/preempt-rt/base was sanity boot tested on
what amounts to a defconfig + RT_FULL on a COTS core2 x86-64 PC
of "end of the Bush era" vintage (ya, I know - stylin kit...)

So even though we've not yet deployed any -rt branches in our 4.6
git kernel, nothing in doing so will change what is presented here.

I'm not posting the full patches here ; nobody on this list wants
a copy of all 300+ rt patches in their inbox.  I've done nothing
technically relevant to the content to warrant such a spamfest.

Paul.

---

The following changes since commit 7b87cb4d769f630c05db6844c0f6654417646ddf:

  cfg/boot-live: Use vfat feature (2016-06-24 17:00:20 -0400)

are available in the git repository at:

  https://github.com/paulgortmaker/yocto-kernel-cache.git yocto-4.6-rt

for you to fetch changes up to 694e6e168120e634837356903ea7c46039e9c6f7:

  4.6.2-rt5 (2016-06-26 18:01:55 -0400)

----
Paul Gortmaker (5):
  powerpc:drop perf build fix now in mainline
  treewide: re-export patches autonominated for refresh
  kver: 4.6 ---> 4.6.1
  treewide: re-export patches autonominated for refresh [4.6 --> 4.6.1]
  rt: remove remaining 4.4 content.

Sebastian Andrzej Siewior (5):
  [ANNOUNCE] 4.6-rc7-rt1
  4.6.1-rt2
  4.6.1-rt3
  4.6.2-rt4
  4.6.2-rt5

 arch/mips/mips-support-preemptible-kernel.patch|   26 +-
 .../perf-tools-Fix-build-break-on-powerpc.patch|   42 -
 arch/powerpc/powerpc.scc   |1 -
 ...ti_malta32-fix-the-pci-resource-conflicts.patch |   18 +-
 ...mips-do-not-set-perf_irq-for-qemu-mips-64.patch |   17 +-
 features/perf/perf-add-SLANG_INC-for-slang.h.patch |   13 +-
 .../perf/perf-add-libperl-not-found-warning.patch  |   13 +-
 ...-change-root-to-prefix-for-python-install.patch |   13 +-
 .../perf/perf-fix-bench-numa-compilation.patch |   15 +-
 ...ips64-Convert-__u64-to-unsigned-long-long.patch |   35 +-
 ...e-lock-unlock-symetry-versus-pi_lock-and-.patch |   42 +
 ...irq-in-translation-section-permission-fau.patch |   85 +
 features/rt/ARM-imx-always-use-TWD-on-IMX6Q.patch  |   30 +
 ...CK-printk-drop-the-logbuf_lock-more-often.patch |   75 +
 ...64-downgrade-preempt_disable-d-region-to-.patch |   51 +
 ...lapic-mark-LAPIC-timer-handler-as-irqsafe.patch |   25 +
 ...vert-acpi_gbl_hardware-lock-back-to-a-raw.patch |  173 ++
 .../rt/arch-arm64-Add-lazy-preempt-support.patch   |  103 +
 ...azy-preempt-add-TIF_NEED_RESCHED_LAZY-to-.patch |   76 +
 ...t-remove-irq-handler-when-clock-is-unused.patch |  146 ++
 ...-at91-tclib-default-to-tclib-timer-for-rt.patch |   32 +
 features/rt/arm-convert-boot-lock-to-raw.patch |  407 
 features/rt/arm-enable-highmem-for-rt.patch|  173 ++
 features/rt/arm-highmem-flush-tlb-on-unmap.patch   |   27 +
 ...rm-lazy-preempt-correct-resched-condition.patch |   31 +
 features/rt/arm-preempt-lazy-support.patch |  105 +
 features/rt/arm-unwind-use_raw_lock.patch  |   83 +
 .../rt/arm64-xen--Make-XEN-depend-on-non-rt.patch  |   23 +
 features/rt/at91_dont_enable_disable_clock.patch   |   91 +
 features/rt/ata-disable-interrupts-if-non-rt.patch |   64 +