diff options
author | Bruce Ashfield <bruce.ashfield@gmail.com> | 2021-05-03 08:54:27 -0400 |
---|---|---|
committer | Anuj Mittal <anuj.mittal@intel.com> | 2021-05-06 10:09:37 +0800 |
commit | 98ae1dd5c60a8f6ca30e80726c81f9fa0fc5d4cb (patch) | |
tree | 88d4fc2d0b6c91e1d046ee4a22d636238d5cc9bf /meta/recipes-kernel/linux/linux-yocto_5.10.bb | |
parent | 2f8edab7ccc80144a7575c8e95c463a161bf5c82 (diff) | |
download | openembedded-core-contrib-98ae1dd5c60a8f6ca30e80726c81f9fa0fc5d4cb.tar.gz |
linux-yocto/5.10: aufs fixes
It was reported that aufs was behaving incorrectly on arm/x86. Although
we don't have an exact fix for the issues, the Wind River guys were able
to come up with a minimal patch set to fix just the core issue, versus
a full aufs uprev.
We didn't have time to get this in before the release, but picking it up
in a dot release is sufficient. (given that it took several months for
the issue to be noticed).
Integrating the following commit(s) to linux-yocto/5.10:
a8808e541750 aufs: linux-v5.10-rc1, no more f_op->read() and ->write()
cb1c41dac775 for aufs: linux-v5.10-rc1, no more vfs_(read|write)f_t
a5805df6583f aufs: linux-v5.10-rc1, no more set_fs()
64e145dcca8c Revert "aufs: initial port to v5.10"
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c290adec4e27f5d7987193e9a0749082f3ed3e20)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Diffstat (limited to 'meta/recipes-kernel/linux/linux-yocto_5.10.bb')
-rw-r--r-- | meta/recipes-kernel/linux/linux-yocto_5.10.bb | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb b/meta/recipes-kernel/linux/linux-yocto_5.10.bb index e6859a2319..2221e99f3c 100644 --- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb +++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb @@ -13,17 +13,17 @@ KBRANCH_qemux86 ?= "v5.10/standard/base" KBRANCH_qemux86-64 ?= "v5.10/standard/base" KBRANCH_qemumips64 ?= "v5.10/standard/mti-malta64" -SRCREV_machine_qemuarm ?= "4f13e8499f2bfc9d95dcc70b981ea16351ff088b" -SRCREV_machine_qemuarm64 ?= "8465e471f5b4855d01012a18cd5fa516061c0358" -SRCREV_machine_qemumips ?= "64f8949180b1a6375abef20eebf735e853701c71" -SRCREV_machine_qemuppc ?= "8465e471f5b4855d01012a18cd5fa516061c0358" -SRCREV_machine_qemuriscv64 ?= "d6e20b2257ecfa6e796a45a4175863862a28fa11" -SRCREV_machine_qemuriscv32 ?= "d6e20b2257ecfa6e796a45a4175863862a28fa11" -SRCREV_machine_qemux86 ?= "d6e20b2257ecfa6e796a45a4175863862a28fa11" -SRCREV_machine_qemux86-64 ?= "d6e20b2257ecfa6e796a45a4175863862a28fa11" -SRCREV_machine_qemumips64 ?= "6bf49ed9b223173d918b7c0140b8d0561bc2674c" -SRCREV_machine ?= "d6e20b2257ecfa6e796a45a4175863862a28fa11" -SRCREV_meta ?= "40a967b115fdbac34fc980d0e27ac2373a031189" +SRCREV_machine_qemuarm ?= "68066f8eb689b650bc95dd5abbba2336e11ca896" +SRCREV_machine_qemuarm64 ?= "a8808e541750d4ed34105f615e295f6fbd9950fa" +SRCREV_machine_qemumips ?= "e609eb0cc21b9037f0adf73dfb524d4e44d0f51c" +SRCREV_machine_qemuppc ?= "a8808e541750d4ed34105f615e295f6fbd9950fa" +SRCREV_machine_qemuriscv64 ?= "a8808e541750d4ed34105f615e295f6fbd9950fa" +SRCREV_machine_qemuriscv32 ?= "a8808e541750d4ed34105f615e295f6fbd9950fa" +SRCREV_machine_qemux86 ?= "a8808e541750d4ed34105f615e295f6fbd9950fa" +SRCREV_machine_qemux86-64 ?= "a8808e541750d4ed34105f615e295f6fbd9950fa" +SRCREV_machine_qemumips64 ?= "f89a64b85a068ac96ccd69f5170b2fbe957d4162" +SRCREV_machine ?= "a8808e541750d4ed34105f615e295f6fbd9950fa" +SRCREV_meta ?= "8f16b5cfe0600f2a7ed1ce68633a88a1196b9776" # remap qemuarm to qemuarma15 for the 5.8 kernel # KMACHINE_qemuarm ?= "qemuarma15" |