#
d9d814ee |
| 13-Jun-2024 |
Steven Rostedt (Google) <rostedt@goodmis.org> |
pstore/ramoops: Add ramoops.mem_name= command line option
Add a method to find a region specified by reserve_mem=nn:align:name for ramoops. Adding a kernel command line parameter:
reserve_mem=12M
pstore/ramoops: Add ramoops.mem_name= command line option
Add a method to find a region specified by reserve_mem=nn:align:name for ramoops. Adding a kernel command line parameter:
reserve_mem=12M:4096:oops ramoops.mem_name=oops
Will use the size and location defined by the memmap parameter where it finds the memory and labels it "oops". The "oops" in the ramoops option is used to search for it.
This allows for arbitrary RAM to be used for ramoops if it is known that the memory is not cleared on kernel crashes or soft reboots.
Tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by: Kees Cook <kees@kernel.org> Link: https://lore.kernel.org/r/20240613155527.591647061@goodmis.org Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
show more ...
|
#
12dc54f5 |
| 10-Jan-2024 |
Nícolas F. R. A. Prado <nfraprado@collabora.com> |
pstore/ram: Register to module device table
Register the compatible for this module on the module device table so it can be automatically loaded when a matching DT node is present, allowing logging
pstore/ram: Register to module device table
Register the compatible for this module on the module device table so it can be automatically loaded when a matching DT node is present, allowing logging of panics and oopses without any intervention.
Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Kees Cook <keescook@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240110210600.787703-2-nfraprado@collabora.com Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
d49270a0 |
| 24-Feb-2023 |
Weichen Chen <weichen.chen@mediatek.com> |
pstore/ram: Fix crash when setting number of cpus to an odd number
When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zon
pstore/ram: Fix crash when setting number of cpus to an odd number
When the number of cpu cores is adjusted to 7 or other odd numbers, the zone size will become an odd number. The address of the zone will become: addr of zone0 = BASE addr of zone1 = BASE + zone_size addr of zone2 = BASE + zone_size*2 ... The address of zone1/3/5/7 will be mapped to non-alignment va. Eventually crashes will occur when accessing these va.
So, use ALIGN_DOWN() to make sure the zone size is even to avoid this bug.
Signed-off-by: Weichen Chen <weichen.chen@mediatek.com> Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Tested-by: "Guilherme G. Piccoli" <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20230224023632.6840-1-weichen.chen@mediatek.com Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
104fd0b5 |
| 27-Jun-2023 |
Yuxiao Zhang <yuxiaozhang@google.com> |
pstore: Support record sizes larger than kmalloc() limit
Currently pstore record buffers are allocated using kmalloc() which has a maximum size based on page size. If a large "pmsg-size" module para
pstore: Support record sizes larger than kmalloc() limit
Currently pstore record buffers are allocated using kmalloc() which has a maximum size based on page size. If a large "pmsg-size" module parameter is specified, pmsg will fail to copy the contents since memdup_user() is limited to kmalloc() allocation sizes.
Since we don't need physically contiguous memory for any of the pstore record buffers, use kvzalloc() to avoid such limitations in the core of pstore and in the ram backend, and explicitly read from userspace using vmemdup_user(). This also means that any other backends that want to (or do already) support larger record sizes will Just Work now.
Signed-off-by: Yuxiao Zhang <yuxiaozhang@google.com> Link: https://lore.kernel.org/r/20230627202540.881909-2-yuxiaozhang@google.com Co-developed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
48f2c681 |
| 01-Apr-2023 |
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> |
pstore/ram: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error ha
pstore/ram: Convert to platform remove callback returning void
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void.
Trivially convert this driver from always returning zero in the remove callback to the void returning variant.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230401120000.2487153-1-u.kleine-koenig@pengutronix.de
show more ...
|
#
beca3e31 |
| 22-Dec-2022 |
Luca Stefani <luca@osomprivacy.com> |
pstore: Properly assign mem_type property
If mem-type is specified in the device tree it would end up overriding the record_size field instead of populating mem_type.
As record_size is currently pa
pstore: Properly assign mem_type property
If mem-type is specified in the device tree it would end up overriding the record_size field instead of populating mem_type.
As record_size is currently parsed after the improper assignment with default size 0 it continued to work as expected regardless of the value found in the device tree.
Simply changing the target field of the struct is enough to get mem-type working as expected.
Fixes: 9d843e8fafc7 ("pstore: Add mem_type property DT parsing support") Cc: stable@vger.kernel.org Signed-off-by: Luca Stefani <luca@osomprivacy.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221222131049.286288-1-luca@osomprivacy.com
show more ...
|
#
e1fce564 |
| 02-Dec-2022 |
Wang Yufen <wangyufen@huawei.com> |
pstore/ram: Fix error return code in ramoops_probe()
In the if (dev_of_node(dev) && !pdata) path, the "err" may be assigned a value of 0, so the error return code -EINVAL may be incorrectly set to 0
pstore/ram: Fix error return code in ramoops_probe()
In the if (dev_of_node(dev) && !pdata) path, the "err" may be assigned a value of 0, so the error return code -EINVAL may be incorrectly set to 0. To fix set valid return code before calling to goto.
Fixes: 35da60941e44 ("pstore/ram: add Device Tree bindings") Signed-off-by: Wang Yufen <wangyufen@huawei.com> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/1669969374-46582-1-git-send-email-wangyufen@huawei.com
show more ...
|
#
06b4e09a |
| 11-Oct-2022 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Set freed addresses to NULL
For good measure, set all the freed addresses to NULL when managing przs.
Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Ton
pstore/ram: Set freed addresses to NULL
For good measure, set all the freed addresses to NULL when managing przs.
Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-and-tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20221011200112.731334-5-keescook@chromium.org
show more ...
|
#
8bd4da0f |
| 11-Oct-2022 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Move internal definitions out of kernel-wide include
Most of the details of the ram backend are entirely internal to the backend itself. Leave only what is needed to instantiate a ram ba
pstore/ram: Move internal definitions out of kernel-wide include
Most of the details of the ram backend are entirely internal to the backend itself. Leave only what is needed to instantiate a ram backend in the kernel-wide header.
Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-and-tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20221011200112.731334-4-keescook@chromium.org
show more ...
|
#
6daf4e82 |
| 11-Oct-2022 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Move pmsg init earlier
Since the ftrace area can vary in size based on CPU count, move pmsg initialization earlier so it will have a stable location.
Suggested-by: Paramjit Oberoi <pso@
pstore/ram: Move pmsg init earlier
Since the ftrace area can vary in size based on CPU count, move pmsg initialization earlier so it will have a stable location.
Suggested-by: Paramjit Oberoi <pso@chromium.org> Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20221011200112.731334-3-keescook@chromium.org
show more ...
|
#
3219122b |
| 11-Oct-2022 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Consolidate kfree() paths
There's no reason to keep separate kfree() paths: either all allocations succeeded, or not. Everything is torn down in the case of failure, so adjust the caller
pstore/ram: Consolidate kfree() paths
There's no reason to keep separate kfree() paths: either all allocations succeeded, or not. Everything is torn down in the case of failure, so adjust the callers to reflect this.
Cc: Anton Vorontsov <anton@enomsg.org> Cc: Colin Cross <ccross@android.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-and-tested-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Link: https://lore.kernel.org/r/20221011200112.731334-2-keescook@chromium.org
show more ...
|
#
9d843e8f |
| 22-Mar-2021 |
Mukesh Ojha <mojha@codeaurora.org> |
pstore: Add mem_type property DT parsing support
There could be a scenario where we define some region in normal memory and use them store to logs which is later retrieved by bootloader during warm
pstore: Add mem_type property DT parsing support
There could be a scenario where we define some region in normal memory and use them store to logs which is later retrieved by bootloader during warm reset.
In this scenario, we wanted to treat this memory as normal cacheable memory instead of default behaviour which is an overhead. Making it cacheable could improve performance.
This commit gives control to change mem_type from Device tree, and also documents the value for normal memory.
Signed-off-by: Mukesh Ojha <mojha@codeaurora.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/1616438537-13719-1-git-send-email-mojha@codeaurora.org
show more ...
|
#
791205e3 |
| 13-May-2020 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Introduce max_reason and convert dump_oops
Now that pstore_register() can correctly pass max_reason to the kmesg dump facility, introduce a new "max_reason" module parameter and "max-rea
pstore/ram: Introduce max_reason and convert dump_oops
Now that pstore_register() can correctly pass max_reason to the kmesg dump facility, introduce a new "max_reason" module parameter and "max-reason" Device Tree field.
The "dump_oops" module parameter and "dump-oops" Device Tree field are now considered deprecated, but are now automatically converted to their corresponding max_reason values when present, though the new max_reason setting has precedence.
For struct ramoops_platform_data, the "dump_oops" member is entirely replaced by a new "max_reason" member, with the only existing user updated in place.
Additionally remove the "reason" filter logic from ramoops_pstore_write(), as that is not specifically needed anymore, though technically this is a change in behavior for any ramoops users also setting the printk.always_kmsg_dump boot param, which will cause ramoops to behave as if max_reason was set to KMSG_DUMP_MAX.
Co-developed-by: Pavel Tatashin <pasha.tatashin@soleen.com> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com> Link: https://lore.kernel.org/lkml/20200515184434.8470-6-keescook@chromium.org/ Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
16a58307 |
| 08-May-2020 |
Kees Cook <keescook@chromium.org> |
pstore/ftrace: Provide ftrace log merging routine
Move the ftrace log merging logic out of pstore/ram into pstore/ftrace so other backends can use it, like pstore/zone.
Link: https://lore.kernel.or
pstore/ftrace: Provide ftrace log merging routine
Move the ftrace log merging logic out of pstore/ram into pstore/ftrace so other backends can use it, like pstore/zone.
Link: https://lore.kernel.org/lkml/20200510202436.63222-7-keescook@chromium.org/ Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
df9bf19d |
| 08-May-2020 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Refactor ftrace buffer merging
This changes the ftrace record merging code to be agnostic of pstore/ram, as the first step to making it available as a generic routine for other backends
pstore/ram: Refactor ftrace buffer merging
This changes the ftrace record merging code to be agnostic of pstore/ram, as the first step to making it available as a generic routine for other backends to use, such as pstore/zone.
Link: https://lore.kernel.org/lkml/20200510202436.63222-6-keescook@chromium.org/ Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
26961d76 |
| 06-May-2020 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Refactor DT size parsing
Refactor device tree size parsing routines to be able to pass a non-zero default value for providing a configurable default for the coming "max_reason" field. Al
pstore/ram: Refactor DT size parsing
Refactor device tree size parsing routines to be able to pass a non-zero default value for providing a configurable default for the coming "max_reason" field. Also rename the helpers, since we're not always parsing a size -- we're parsing a u32 and making sure it's not greater than INT_MAX.
Link: https://lore.kernel.org/lkml/20200506211523.15077-4-keescook@chromium.org/ Link: https://lore.kernel.org/lkml/20200521205223.175957-1-tyhicks@linux.microsoft.com Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
f858b57f |
| 06-May-2020 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Adjust module param permissions to reflect reality
A couple module parameters had 0600 permissions, but changing them would have no impact on ramoops, so switch these to 0400 to reflect
pstore/ram: Adjust module param permissions to reflect reality
A couple module parameters had 0600 permissions, but changing them would have no impact on ramoops, so switch these to 0400 to reflect reality.
Link: https://lore.kernel.org/lkml/20200506211523.15077-7-keescook@chromium.org/ Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
e030b80f |
| 07-Feb-2020 |
chenqiwu <chenqiwu@xiaomi.com> |
pstore/ram: remove unnecessary ramoops_unregister_dummy()
Remove unnecessary ramoops_unregister_dummy() if ramoops platform device register failed.
Signed-off-by: chenqiwu <chenqiwu@xiaomi.com> Lin
pstore/ram: remove unnecessary ramoops_unregister_dummy()
Remove unnecessary ramoops_unregister_dummy() if ramoops platform device register failed.
Signed-off-by: chenqiwu <chenqiwu@xiaomi.com> Link: https://lore.kernel.org/r/1581068800-13817-2-git-send-email-qiwuchen55@gmail.com Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
e163fdb3 |
| 08-Jan-2020 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Regularize prz label allocation lifetime
In my attempt to fix a memory leak, I introduced a double-free in the pstore error path. Instead of trying to manage the allocation lifetime betw
pstore/ram: Regularize prz label allocation lifetime
In my attempt to fix a memory leak, I introduced a double-free in the pstore error path. Instead of trying to manage the allocation lifetime between persistent_ram_new() and its callers, adjust the logic so persistent_ram_new() always takes a kstrdup() copy, and leaves the caller's allocation lifetime up to the caller. Therefore callers are _always_ responsible for freeing their label. Before, it only needed freeing when the prz itself failed to allocate, and not in any of the other prz failure cases, which callers would have no visibility into, which is the root design problem that lead to both the leak and now double-free bugs.
Reported-by: Cengiz Can <cengiz@kernel.wtf> Link: https://lore.kernel.org/lkml/d4ec59002ede4aaf9928c7f7526da87c@kernel.wtf Fixes: 8df955a32a73 ("pstore/ram: Fix error-path memory leak in persistent_ram_new() callers") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
9e5f1c19 |
| 23-Dec-2019 |
Aleksandr Yashkin <a.yashkin@inango-systems.com> |
pstore/ram: Write new dumps to start of recycled zones
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
pstore/ram: Write new dumps to start of recycled zones
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@inango-systems.com> Signed-off-by: Nikolay Merinov <n.merinov@inango-systems.com> Signed-off-by: Ariel Gilman <a.gilman@inango-systems.com> Link: https://lore.kernel.org/r/20191223133816.28155-1-n.merinov@inango-systems.com Fixes: 896fc1f0c4c6 ("pstore/ram: Switch to persistent_ram routines") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
8df955a3 |
| 30-Dec-2019 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Fix error-path memory leak in persistent_ram_new() callers
For callers that allocated a label for persistent_ram_new(), if the call fails, they must clean up the allocation.
Suggested-b
pstore/ram: Fix error-path memory leak in persistent_ram_new() callers
For callers that allocated a label for persistent_ram_new(), if the call fails, they must clean up the allocation.
Suggested-by: Navid Emamdoost <navid.emamdoost@gmail.com> Fixes: 1227daa43bce ("pstore/ram: Clarify resource reservation labels") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/lkml/20191211191353.14385-1-navid.emamdoost@gmail.com Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
83b8a3fb |
| 23-Jun-2019 |
Deepa Dinamani <deepa.kernel@gmail.com> |
pstore: fs superblock limits
Leaving granularity at 1ns because it is dependent on the specific attached backing pstore module. ramoops has microsecond resolution.
Fix the readback of ramoops fract
pstore: fs superblock limits
Leaving granularity at 1ns because it is dependent on the specific attached backing pstore module. ramoops has microsecond resolution.
Fix the readback of ramoops fractional timestamp microseconds, which has incorrectly been reporting the value as nanoseconds.
Fixes: 3f8f80f0cfeb ("pstore/ram: Read and write to the 'compressed' flag of pstore").
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com> Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Jeff Layton <jlayton@kernel.org> Cc: anton@enomsg.org Cc: ccross@android.com Cc: keescook@chromium.org Cc: tony.luck@intel.com
show more ...
|
#
1614e921 |
| 08-May-2019 |
Douglas Anderson <dianders@chromium.org> |
pstore/ram: Improve backward compatibility with older Chromebooks
When you try to run an upstream kernel on an old ARM-based Chromebook you'll find that console-ramoops doesn't work.
Old ARM-based
pstore/ram: Improve backward compatibility with older Chromebooks
When you try to run an upstream kernel on an old ARM-based Chromebook you'll find that console-ramoops doesn't work.
Old ARM-based Chromebooks, before <https://crrev.com/c/439792> ("ramoops: support upstream {console,pmsg,ftrace}-size properties") used to create a "ramoops" node at the top level that looked like:
/ { ramoops { compatible = "ramoops"; reg = <...>; record-size = <...>; dump-oops; }; };
...and these Chromebooks assumed that the downstream kernel would make console_size / pmsg_size match the record size. The above ramoops node was added by the firmware so it's not easy to make any changes.
Let's match the expected behavior, but only for those using the old backward-compatible way of working where ramoops is right under the root node.
NOTE: if there are some out-of-tree devices that had ramoops at the top level, left everything but the record size as 0, and somehow doesn't want this behavior, we can try to add more conditions here.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|
#
2b27bdcc |
| 29-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 336
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of th
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 336
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope that it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 51 franklin st fifth floor boston ma 02110 1301 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 246 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000436.674189849@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
8880fa32 |
| 31-May-2019 |
Kees Cook <keescook@chromium.org> |
pstore/ram: Run without kernel crash dump region
The ram pstore backend has always had the crash dumper frontend enabled unconditionally. However, it was possible to effectively disable it by settin
pstore/ram: Run without kernel crash dump region
The ram pstore backend has always had the crash dumper frontend enabled unconditionally. However, it was possible to effectively disable it by setting a record_size=0. All the machinery would run (storing dumps to the temporary crash buffer), but 0 bytes would ultimately get stored due to there being no przs allocated for dumps. Commit 89d328f637b9 ("pstore/ram: Correctly calculate usable PRZ bytes"), however, assumed that there would always be at least one allocated dprz for calculating the size of the temporary crash buffer. This was, of course, not the case when record_size=0, and would lead to a NULL deref trying to find the dprz buffer size:
BUG: unable to handle kernel NULL pointer dereference at (null) ... IP: ramoops_probe+0x285/0x37e (fs/pstore/ram.c:808)
cxt->pstore.bufsize = cxt->dprzs[0]->buffer_size;
Instead, we need to only enable the frontends based on the success of the prz initialization and only take the needed actions when those zones are available. (This also fixes a possible error in detecting if the ftrace frontend should be enabled.)
Reported-and-tested-by: Yaro Slav <yaro330@gmail.com> Fixes: 89d328f637b9 ("pstore/ram: Correctly calculate usable PRZ bytes") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org>
show more ...
|