kernel.git/fs/pstore, branch linux-4.4.y

pstore/ram: Write new dumps to start of recycled zones

2020-01-12T10:22:46Z

[ 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 Signed-off-by: Nikolay Merinov Signed-off-by: Ariel Gilman Link: https://lore.kernel.org/r/20191223133816.28155-1-n.merinov@inango-systems.com Fixes: 896fc1f0c4c6 ("pstore/ram: Switch to persistent_ram routines") [kees: backport to v4.9] Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

pstore/ram: Do not treat empty buffers as valid

2019-01-26T08:42:53Z

[ Upstream commit 30696378f68a9e3dad6bfe55938b112e72af00c2 ] The ramoops backend currently calls persistent_ram_save_old() even if a buffer is empty. While this appears to work, it is does not seem like the right thing to do and could lead to future bugs so lets avoid that. It also prevents misleading prints in the logs which claim the buffer is valid. I got something like: found existing buffer, size 0, start 0 When I was expecting: no valid data in buffer (sig = ...) This bails out early (and reports with pr_debug()), since it's an acceptable state. Signed-off-by: Joel Fernandes (Google) Co-developed-by: Kees Cook Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

pstore: Convert console write to use ->write_buf

2018-12-17T20:55:12Z

[ Upstream commit 70ad35db3321a6d129245979de4ac9d06eed897c ] Maybe I'm missing something, but I don't know why it needs to copy the input buffer to psinfo->buf and then write. Instead we can write the input buffer directly. The only implementation that supports console message (i.e. ramoops) already does it for ftrace messages. For the upcoming virtio backend driver, it needs to protect psinfo->buf overwritten from console messages. If it could use ->write_buf method instead of ->write, the problem will be solved easily. Cc: Stefan Hajnoczi Signed-off-by: Namhyung Kim Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

pstore: Fix incorrect persistent ram buffer mapping

2018-09-26T06:35:07Z

commit 831b624df1b420c8f9281ed1307a8db23afb72df upstream. persistent_ram_vmap() returns the page start vaddr. persistent_ram_iomap() supports non-page-aligned mapping. persistent_ram_buffer_map() always adds offset-in-page to the vaddr returned from these two functions, which causes incorrect mapping of non-page-aligned persistent ram buffer. By default ftrace_size is 4096 and max_ftrace_cnt is nr_cpu_ids. Without this patch, the zone_sz in ramoops_init_przs() is 4096/nr_cpu_ids which might not be page aligned. If the offset-in-page > 2048, the vaddr will be in next page. If the next page is not mapped, it will cause kernel panic: [ 0.074231] BUG: unable to handle kernel paging request at ffffa19e0081b000 ... [ 0.075000] RIP: 0010:persistent_ram_new+0x1f8/0x39f ... [ 0.075000] Call Trace: [ 0.075000] ramoops_init_przs.part.10.constprop.15+0x105/0x260 [ 0.075000] ramoops_probe+0x232/0x3a0 [ 0.075000] platform_drv_probe+0x3e/0xa0 [ 0.075000] driver_probe_device+0x2cd/0x400 [ 0.075000] __driver_attach+0xe4/0x110 [ 0.075000] ? driver_probe_device+0x400/0x400 [ 0.075000] bus_for_each_dev+0x70/0xa0 [ 0.075000] driver_attach+0x1e/0x20 [ 0.075000] bus_add_driver+0x159/0x230 [ 0.075000] ? do_early_param+0x95/0x95 [ 0.075000] driver_register+0x70/0xc0 [ 0.075000] ? init_pstore_fs+0x4d/0x4d [ 0.075000] __platform_driver_register+0x36/0x40 [ 0.075000] ramoops_init+0x12f/0x131 [ 0.075000] do_one_initcall+0x4d/0x12c [ 0.075000] ? do_early_param+0x95/0x95 [ 0.075000] kernel_init_freeable+0x19b/0x222 [ 0.075000] ? rest_init+0xbb/0xbb [ 0.075000] kernel_init+0xe/0xfc [ 0.075000] ret_from_fork+0x3a/0x50 Signed-off-by: Bin Yang [kees: add comments describing the mapping differences, updated commit log] Fixes: 24c3d2f342ed ("staging: android: persistent_ram: Make it possible to use memory outside of bootmem") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

pstore: Use dynamic spinlock initializer

2017-08-07T02:19:43Z

commit e9a330c4289f2ba1ca4bf98c2b430ab165a8931b upstream. The per-prz spinlock should be using the dynamic initializer so that lockdep can correctly track it. Without this, under lockdep, we get a warning at boot that the lock is in non-static memory. Fixes: 109704492ef6 ("pstore: Make spinlock per zone instead of global") Fixes: 76d5692a5803 ("pstore: Correctly initialize spinlock and flags") Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

pstore: Correctly initialize spinlock and flags

2017-08-07T02:19:43Z

commit 76d5692a58031696e282384cbd893832bc92bd76 upstream. The ram backend wasn't always initializing its spinlock correctly. Since it was coming from kzalloc memory, though, it was harmless on architectures that initialize unlocked spinlocks to 0 (at least x86 and ARM). This also fixes a possibly ignored flag setting too. When running under CONFIG_DEBUG_SPINLOCK, the following Oops was visible: [ 0.760836] persistent_ram: found existing buffer, size 29988, start 29988 [ 0.765112] persistent_ram: found existing buffer, size 30105, start 30105 [ 0.769435] persistent_ram: found existing buffer, size 118542, start 118542 [ 0.785960] persistent_ram: found existing buffer, size 0, start 0 [ 0.786098] persistent_ram: found existing buffer, size 0, start 0 [ 0.786131] pstore: using zlib compression [ 0.790716] BUG: spinlock bad magic on CPU#0, swapper/0/1 [ 0.790729] lock: 0xffffffc0d1ca9bb0, .magic: 00000000, .owner: /-1, .owner_cpu: 0 [ 0.790742] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.10.0-rc2+ #913 [ 0.790747] Hardware name: Google Kevin (DT) [ 0.790750] Call trace: [ 0.790768] [] dump_backtrace+0x0/0x2bc [ 0.790780] [] show_stack+0x20/0x28 [ 0.790794] [] dump_stack+0xa4/0xcc [ 0.790809] [] spin_dump+0xe0/0xf0 [ 0.790821] [] spin_bug+0x30/0x3c [ 0.790834] [] do_raw_spin_lock+0x50/0x1b8 [ 0.790846] [] _raw_spin_lock_irqsave+0x54/0x6c [ 0.790862] [] buffer_size_add+0x48/0xcc [ 0.790875] [] persistent_ram_write+0x60/0x11c [ 0.790888] [] ramoops_pstore_write_buf+0xd4/0x2a4 [ 0.790900] [] pstore_console_write+0xf0/0x134 [ 0.790912] [] console_unlock+0x48c/0x5e8 [ 0.790923] [] register_console+0x3b0/0x4d4 [ 0.790935] [] pstore_register+0x1a8/0x234 [ 0.790947] [] ramoops_probe+0x6b8/0x7d4 [ 0.790961] [] platform_drv_probe+0x7c/0xd0 [ 0.790972] [] driver_probe_device+0x1b4/0x3bc [ 0.790982] [] __device_attach_driver+0xc8/0xf4 [ 0.790996] [] bus_for_each_drv+0xb4/0xe4 [ 0.791006] [] __device_attach+0xd0/0x158 [ 0.791016] [] device_initial_probe+0x24/0x30 [ 0.791026] [] bus_probe_device+0x50/0xe4 [ 0.791038] [] device_add+0x3a4/0x76c [ 0.791051] [] of_device_add+0x74/0x84 [ 0.791062] [] of_platform_device_create_pdata+0xc0/0x100 [ 0.791073] [] of_platform_device_create+0x34/0x40 [ 0.791086] [] of_platform_default_populate_init+0x58/0x78 [ 0.791097] [] do_one_initcall+0x88/0x160 [ 0.791109] [] kernel_init_freeable+0x264/0x31c [ 0.791123] [] kernel_init+0x18/0x11c [ 0.791133] [] ret_from_fork+0x10/0x50 [ 0.793717] console [pstore-1] enabled [ 0.797845] pstore: Registered ramoops as persistent store backend [ 0.804647] ramoops: attached 0x100000@0xf7edc000, ecc: 0/0 Fixes: 663deb47880f ("pstore: Allow prz to control need for locking") Fixes: 109704492ef6 ("pstore: Make spinlock per zone instead of global") Reported-by: Brian Norris Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

pstore: Allow prz to control need for locking

2017-08-07T02:19:43Z

commit 663deb47880f2283809669563c5a52ac7c6aef1a upstream. In preparation of not locking at all for certain buffers depending on if there's contention, make locking optional depending on the initialization of the prz. Signed-off-by: Joel Fernandes [kees: moved locking flag into prz instead of via caller arguments] Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

pstore: Make spinlock per zone instead of global

2017-08-07T02:19:38Z

commit 109704492ef637956265ec2eb72ae7b3b39eb6f4 upstream. Currently pstore has a global spinlock for all zones. Since the zones are independent and modify different areas of memory, there's no need to have a global lock, so we should use a per-zone lock as introduced here. Also, when ramoops's ftrace use-case has a FTRACE_PER_CPU flag introduced later, which splits the ftrace memory area into a single zone per CPU, it will eliminate the need for locking. In preparation for this, make the locking optional. Signed-off-by: Joel Fernandes [kees: updated commit message] Signed-off-by: Kees Cook Cc: Leo Yan Signed-off-by: Greg Kroah-Hartman

pstore/ram: Use memcpy_fromio() to save old buffer

2016-10-28T07:01:27Z

commit d771fdf94180de2bd811ac90cba75f0f346abf8d upstream. The ramoops buffer may be mapped as either I/O memory or uncached memory. On ARM64, this results in a device-type (strongly-ordered) mapping. Since unnaligned accesses to device-type memory will generate an alignment fault (regardless of whether or not strict alignment checking is enabled), it is not safe to use memcpy(). memcpy_fromio() is guaranteed to only use aligned accesses, so use that instead. Signed-off-by: Andrew Bresticker Signed-off-by: Enric Balletbo Serra Reviewed-by: Puneet Kumar Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman

pstore/ram: Use memcpy_toio instead of memcpy

2016-10-28T07:01:27Z

commit 7e75678d23167c2527e655658a8ef36a36c8b4d9 upstream. persistent_ram_update uses vmap / iomap based on whether the buffer is in memory region or reserved region. However, both map it as non-cacheable memory. For armv8 specifically, non-cacheable mapping requests use a memory type that has to be accessed aligned to the request size. memcpy() doesn't guarantee that. Signed-off-by: Furquan Shaikh Signed-off-by: Enric Balletbo Serra Reviewed-by: Aaron Durbin Reviewed-by: Olof Johansson Tested-by: Furquan Shaikh Signed-off-by: Kees Cook Signed-off-by: Greg Kroah-Hartman