From: Aleksandr Yashkin <a.yashkin(a)inango-systems.com>
[ Upstream commit 9e5f1c19800b808a37fb9815a26d382132c26c3d ]
The ram_core.c routines treat przs as circular buffers. When writing a
new crash dump, the old buffer needs to be cleared so that the new dump
doesn't end up in the wrong place (i.e. at the end).
The solution to this problem is to reset the circular buffer state before
writing a new Oops dump.
Signed-off-by: Aleksandr Yashkin <a.yashkin(a)inango-systems.com>
Signed-off-by: Nikolay Merinov <n.merinov(a)inango-systems.com>
Signed-off-by: Ariel Gilman <a.gilman(a)inango-systems.com>
Link: https://lore.kernel.org/r/20191223133816.28155-1-n.merinov@inango-systems.c…
Fixes: 896fc1f0c4c6 ("pstore/ram: Switch to persistent_ram routines")
[kees: backport to v4.9]
Link: https://lore.kernel.org/stable/157831399811194@kroah.com
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
fs/pstore/ram.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 8b09271e5d66..a73959e6ae32 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -321,6 +321,17 @@ static int notrace ramoops_pstore_write_buf(enum pstore_type_id type,
prz = cxt->przs[cxt->dump_write_cnt];
+ /*
+ * Since this is a new crash dump, we need to reset the buffer in
+ * case it still has an old dump present. Without this, the new dump
+ * will get appended, which would seriously confuse anything trying
+ * to check dump file contents. Specifically, ramoops_read_kmsg_hdr()
+ * expects to find a dump header in the beginning of buffer data, so
+ * we must to reset the buffer values, in order to ensure that the
+ * header will be written to the beginning of the buffer.
+ */
+ persistent_ram_zap(prz);
+
hlen = ramoops_write_kmsg_hdr(prz, compressed);
if (size + hlen > prz->buffer_size)
size = prz->buffer_size - hlen;
--
2.20.1
--
Kees Cook
Hi,
On 07-01-2020 19:33, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.4.8, v4.19.93, v4.14.162, v4.9.208, v4.4.208.
>
> v5.4.8: Failed to apply! Possible dependencies:
> a5242f4858be ("gpiolib: acpi: Turn dmi_system_id table into a generic quirk table")
>
> v4.19.93: Failed to apply! Possible dependencies:
> a5242f4858be ("gpiolib: acpi: Turn dmi_system_id table into a generic quirk table")
>
> v4.14.162: Failed to apply! Possible dependencies:
> a5242f4858be ("gpiolib: acpi: Turn dmi_system_id table into a generic quirk table")
>
Like with the previous patch adding this to 4.14 and later (which should apply cleanly once
the previous patch is applied) , leaving the others behind should be fine.
Thanks,
Hans
> v4.9.208: Failed to apply! Possible dependencies:
> 25e3ef894eef ("gpio: acpi: Split out acpi_gpio_get_irq_resource() helper")
> 2727315df3f5 ("gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist")
> 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist")
> 78d3a92edbfb ("gpiolib-acpi: Register GpioInt ACPI event handlers from a late_initcall")
> 85c73d50e57e ("gpio: acpi: Add managed variant of acpi_dev_add_driver_gpios()")
> 8a146fbe1f14 ("gpio: acpi: Call enable_irq_wake for _IAE GpioInts with Wake set")
> 993b9bc5c47f ("gpiolib: acpi: Switch to cansleep version of GPIO library call")
> a5242f4858be ("gpiolib: acpi: Turn dmi_system_id table into a generic quirk table")
> ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot")
> e59f5e08ece1 ("gpiolib-acpi: Only defer request_irq for GpioInt ACPI event handlers")
>
> v4.4.208: Failed to apply! Possible dependencies:
> 10cf4899f8af ("gpiolib: tighten up ACPI legacy gpio lookups")
> 25e3ef894eef ("gpio: acpi: Split out acpi_gpio_get_irq_resource() helper")
> 58383c78425e ("gpio: change member .dev to .parent")
> 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist")
> 78d3a92edbfb ("gpiolib-acpi: Register GpioInt ACPI event handlers from a late_initcall")
> 85c73d50e57e ("gpio: acpi: Add managed variant of acpi_dev_add_driver_gpios()")
> 8a146fbe1f14 ("gpio: acpi: Call enable_irq_wake for _IAE GpioInts with Wake set")
> 993b9bc5c47f ("gpiolib: acpi: Switch to cansleep version of GPIO library call")
> a5242f4858be ("gpiolib: acpi: Turn dmi_system_id table into a generic quirk table")
> ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot")
> e59f5e08ece1 ("gpiolib-acpi: Only defer request_irq for GpioInt ACPI event handlers")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
Hi,
On 07-01-2020 19:33, Sasha Levin wrote:
> Hi,
>
> [This is an automated email]
>
> This commit has been processed because it contains a -stable tag.
> The stable tag indicates that it's relevant for the following trees: all
>
> The bot has tested the following trees: v5.4.8, v4.19.93, v4.14.162, v4.9.208, v4.4.208.
>
> v5.4.8: Build OK!
> v4.19.93: Build OK!
> v4.14.162: Build OK!
Adding this to 4.14 and later, leaving the others behind should be fine.
Thanks,
Hans
> v4.9.208: Failed to apply! Possible dependencies:
> 25e3ef894eef ("gpio: acpi: Split out acpi_gpio_get_irq_resource() helper")
> 2727315df3f5 ("gpiolib: acpi: Add Terra Pad 1061 to the run_edge_events_on_boot_blacklist")
> 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist")
> 78d3a92edbfb ("gpiolib-acpi: Register GpioInt ACPI event handlers from a late_initcall")
> 85c73d50e57e ("gpio: acpi: Add managed variant of acpi_dev_add_driver_gpios()")
> 8a146fbe1f14 ("gpio: acpi: Call enable_irq_wake for _IAE GpioInts with Wake set")
> 993b9bc5c47f ("gpiolib: acpi: Switch to cansleep version of GPIO library call")
> ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot")
> e59f5e08ece1 ("gpiolib-acpi: Only defer request_irq for GpioInt ACPI event handlers")
>
> v4.4.208: Failed to apply! Possible dependencies:
> 10cf4899f8af ("gpiolib: tighten up ACPI legacy gpio lookups")
> 25e3ef894eef ("gpio: acpi: Split out acpi_gpio_get_irq_resource() helper")
> 58383c78425e ("gpio: change member .dev to .parent")
> 61f7f7c8f978 ("gpiolib: acpi: Add gpiolib_acpi_run_edge_events_on_boot option and blacklist")
> 78d3a92edbfb ("gpiolib-acpi: Register GpioInt ACPI event handlers from a late_initcall")
> 85c73d50e57e ("gpio: acpi: Add managed variant of acpi_dev_add_driver_gpios()")
> 8a146fbe1f14 ("gpio: acpi: Call enable_irq_wake for _IAE GpioInts with Wake set")
> 993b9bc5c47f ("gpiolib: acpi: Switch to cansleep version of GPIO library call")
> ca876c7483b6 ("gpiolib-acpi: make sure we trigger edge events at least once on boot")
> e59f5e08ece1 ("gpiolib-acpi: Only defer request_irq for GpioInt ACPI event handlers")
>
>
> NOTE: The patch will not be queued to stable trees until it is upstream.
>
> How should we proceed with this patch?
>
Following build error on stable-rc 5.4.9-rc1 for arm architecture.
dma/direct.c: In function 'dma_direct_possible':
dma/direct.c:329:3: error: too many arguments to function 'dma_capable'
dma_capable(dev, dma_addr, size, true);
^~~~~~~~~~~
In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/dma-direct.h:12:0,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/kernel/dma/direct.c:10:
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/arch/arm/include/asm/dma-direct.h:17:20:
note: declared here
static inline bool dma_capable(struct device *dev, dma_addr_t addr,
size_t size)
^~~~~~~~~~~
In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/init.h:5:0,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/memblock.h:12,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/kernel/dma/direct.c:7:
dma/direct.c: In function 'dma_direct_map_resource':
dma/direct.c:378:16: error: too many arguments to function 'dma_capable'
if (unlikely(!dma_capable(dev, dma_addr, size, false))) {
^
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/compiler.h:78:42:
note: in definition of macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
In file included from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/include/linux/dma-direct.h:12:0,
from
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/kernel/dma/direct.c:10:
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/arch/arm/include/asm/dma-direct.h:17:20:
note: declared here
static inline bool dma_capable(struct device *dev, dma_addr_t addr,
size_t size)
^~~~~~~~~~~
/srv/oe/build/tmp-lkft-glibc/work-shared/am57xx-evm/kernel-source/scripts/Makefile.build:265:
recipe for target 'kernel/dma/direct.o' failed
Full build log link,
https://ci.linaro.org/view/lkft/job/openembedded-lkft-linux-stable-rc-5.4/D…
--
Linaro LKFT
https://lkft.linaro.org
Hello!
Phillipp has asked me whether I could send commits:
cba22d86e0a1 bdev: Refresh bdev size for disks without partitioning
731dc4868311 bdev: Factor out bdev revalidation into a common helper
for inclusion into stable. I've noticed they are already in 5.4-stable but
they didn't seem to propagate into say 4.19-stable although they apply just
fine there. Any reason for that?
The fixes fix mounting of encrypted UDF media for some setups and they are
reasonably safe so I'm fine with pushing them to stable.
Thanks!
Honza
--
Jan Kara <jack(a)suse.com>
SUSE Labs, CR
Hello,
We ran automated tests on a recent commit from this kernel tree:
Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Commit: 9d117060a151 - Linux 5.4.9-rc1
The results of these automated tests are provided below.
Overall result: FAILED (see details below)
Merge: OK
Compile: FAILED
All kernel binaries, config files, and logs are available for download here:
https://artifacts.cki-project.org/pipelines/370824
We attempted to compile the kernel for multiple architectures, but the compile
failed on one or more architectures:
ppc64le: FAILED (see build-ppc64le.log.xz attachment)
We hope that these logs can help you find the problem quickly. For the full
detail on our testing procedures, please scroll to the bottom of this message.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
Compile testing
---------------
We compiled the kernel for 3 architectures:
aarch64:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
ppc64le:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
x86_64:
make options: -j30 INSTALL_MOD_STRIP=1 targz-pkg
----- On Dec 25, 2019, at 6:39 AM, Borislav Petkov bp(a)alien8.de wrote:
> On Wed, Dec 25, 2019 at 10:38:53AM -0000, tip-bot2 for Mathieu Desnoyers wrote:
>> The following commit has been merged into the core/urgent branch of tip:
>>
>> Commit-ID: 66528a4575eee9f5a5270219894ab6178f146e84
>> Gitweb:
>> https://git.kernel.org/tip/66528a4575eee9f5a5270219894ab6178f146e84
>> Author: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
>> AuthorDate: Wed, 11 Dec 2019 11:17:11 -05:00
>> Committer: Ingo Molnar <mingo(a)kernel.org>
>> CommitterDate: Wed, 25 Dec 2019 10:41:20 +01:00
>>
>> rseq: Reject unknown flags on rseq unregister
>>
>> It is preferrable to reject unknown flags within rseq unregistration
>> rather than to ignore them. It is an oversight caused by the fact that
>> the check for unknown flags is after the rseq unregister flag check.
>>
>> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com>
>> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
>> Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
>> Cc: Peter Zijlstra <peterz(a)infradead.org>
>> Cc: Thomas Gleixner <tglx(a)linutronix.de>
>> Link:
>> https://lkml.kernel.org/r/20191211161713.4490-2-mathieu.desnoyers@efficios.…
>> Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
>> ---
>> kernel/rseq.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/kernel/rseq.c b/kernel/rseq.c
>> index 27c48eb..a4f86a9 100644
>> --- a/kernel/rseq.c
>> +++ b/kernel/rseq.c
>> @@ -310,6 +310,8 @@ SYSCALL_DEFINE4(rseq, struct rseq __user *, rseq, u32,
>> rseq_len,
>> int ret;
>>
>> if (flags & RSEQ_FLAG_UNREGISTER) {
>> + if (flags & ~RSEQ_FLAG_UNREGISTER)
>> + return -EINVAL;
>> /* Unregister rseq for current thread. */
>> if (current->rseq != rseq || !current->rseq)
>> return -EINVAL;
>
> Cc: stable perhaps?
This could indeed be a candidate for stable, even though it's just a stricter
checking of unknown flags (returning an error rather than ignoring them).
Adding stable in CC here.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com