kernel.git/fs/pstore/ram.c, branch linux-rolling-lts

Get rid of 'remove_new' relic from platform driver struct

2024-12-01T23:12:43Z

The continual trickle of small conversion patches is grating on me, and is really not helping. Just get rid of the 'remove_new' member function, which is just an alias for the plain 'remove', and had a comment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */ This was just a tree-wide 'sed' script that replaced '.remove_new' with '.remove', with some care taken to turn a subsequent tab into two tabs to make things line up. I did do some minimal manual whitespace adjustment for places that used spaces to line things up. Then I just removed the old (sic) .remove_new member function, and this is the end result. No more unnecessary conversion noise. Signed-off-by: Linus Torvalds

pstore/ramoops: Add ramoops.mem_name= command line option

2024-06-19T15:05:14Z

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 Signed-off-by: Steven Rostedt (Google) Acked-by: Kees Cook Link: https://lore.kernel.org/r/20240613155527.591647061@goodmis.org Signed-off-by: Mike Rapoport (IBM)

pstore/ram: Register to module device table

2024-02-22T18:37:21Z

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 Reviewed-by: Kees Cook Reviewed-by: AngeloGioacchino Del Regno Link: https://lore.kernel.org/r/20240110210600.787703-2-nfraprado@collabora.com Signed-off-by: Kees Cook

pstore/ram: Fix crash when setting number of cpus to an odd number

2023-12-08T22:15:00Z

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 Reviewed-by: Matthias Brugger Tested-by: "Guilherme G. Piccoli" Link: https://lore.kernel.org/r/20230224023632.6840-1-weichen.chen@mediatek.com Signed-off-by: Kees Cook

pstore: Support record sizes larger than kmalloc() limit

2023-08-17T22:18:24Z

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 Link: https://lore.kernel.org/r/20230627202540.881909-2-yuxiaozhang@google.com Co-developed-by: Kees Cook Signed-off-by: Kees Cook

pstore/ram: Convert to platform remove callback returning void

2023-05-10T21:06:00Z

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 Reviewed-by: Guilherme G. Piccoli Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20230401120000.2487153-1-u.kleine-koenig@pengutronix.de

pstore: Properly assign mem_type property

2022-12-23T18:34:25Z

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 Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20221222131049.286288-1-luca@osomprivacy.com

pstore/ram: Fix error return code in ramoops_probe()

2022-12-02T23:16:59Z

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 Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/1669969374-46582-1-git-send-email-wangyufen@huawei.com

pstore/ram: Set freed addresses to NULL

2022-10-19T16:25:39Z

For good measure, set all the freed addresses to NULL when managing przs. Cc: Anton Vorontsov Cc: Colin Cross Cc: Tony Luck Signed-off-by: Kees Cook Reviewed-and-tested-by: Guilherme G. Piccoli Link: https://lore.kernel.org/r/20221011200112.731334-5-keescook@chromium.org

pstore/ram: Move internal definitions out of kernel-wide include

2022-10-17T20:14:32Z

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 Cc: Colin Cross Cc: Tony Luck Signed-off-by: Kees Cook Reviewed-and-tested-by: Guilherme G. Piccoli Link: https://lore.kernel.org/r/20221011200112.731334-4-keescook@chromium.org