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

pstore/ram: Do not treat empty buffers as valid

2019-01-26T08:44:27Z

[ 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-17T09:07: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:33:57Z

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-11T16:30:11Z

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-11T16:30:11Z

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-11T16:30:11Z

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-11T16:30:08Z

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: Allow optional mapping with pgprot_noncached

2015-01-16T14:59:47Z

commit 027bc8b08242c59e19356b4b2c189f2d849ab660 upstream. On some ARMs the memory can be mapped pgprot_noncached() and still be working for atomic operations. As pointed out by Colin Cross , in some cases you do want to use pgprot_noncached() if the SoC supports it to see a debug printk just before a write hanging the system. On ARMs, the atomic operations on strongly ordered memory are implementation defined. So let's provide an optional kernel parameter for configuring pgprot_noncached(), and use pgprot_writecombine() by default. Cc: Arnd Bergmann Cc: Rob Herring Cc: Randy Dunlap Cc: Anton Vorontsov Cc: Colin Cross Cc: Olof Johansson Cc: Russell King Acked-by: Kees Cook Signed-off-by: Tony Lindgren Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman

pstore-ram: Fix hangs by using write-combine mappings

2015-01-16T14:59:47Z

commit 7ae9cb81933515dc7db1aa3c47ef7653717e3090 upstream. Currently trying to use pstore on at least ARMs can hang as we're mapping the peristent RAM with pgprot_noncached(). On ARMs, pgprot_noncached() will actually make the memory strongly ordered, and as the atomic operations pstore uses are implementation defined for strongly ordered memory, they may not work. So basically atomic operations have undefined behavior on ARM for device or strongly ordered memory types. Let's fix the issue by using write-combine variants for mappings. This corresponds to normal, non-cacheable memory on ARM. For many other architectures, this change does not change the mapping type as by default we have: #define pgprot_writecombine pgprot_noncached The reason why pgprot_noncached() was originaly used for pstore is because Colin Cross had observed lost debug prints right before a device hanging write operation on some systems. For the platforms supporting pgprot_noncached(), we can add a an optional configuration option to support that. But let's get pstore working first before adding new features. Cc: Arnd Bergmann Cc: Anton Vorontsov Cc: Colin Cross Cc: Olof Johansson Cc: linux-kernel@vger.kernel.org Acked-by: Kees Cook Signed-off-by: Rob Herring [tony@atomide.com: updated description] Signed-off-by: Tony Lindgren Signed-off-by: Tony Luck Signed-off-by: Greg Kroah-Hartman

pstore: Fix duplicate {console,ftrace}-efi entries

2014-10-15T20:51:33Z

The pstore filesystem still creates duplicate filename/inode pairs for some pstore types. Add the id to the filename to prevent that. Before patch: [/sys/fs/pstore] ls -li total 0 1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi 1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi 1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi 1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi 1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi 1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi 1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi 1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi 1250 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi After: [/sys/fs/pstore] ls -li total 0 1232 -r--r--r--. 1 root root 148 Sep 29 17:09 console-efi-141202499100000 1231 -r--r--r--. 1 root root 67 Sep 29 17:09 console-efi-141202499200000 1230 -r--r--r--. 1 root root 148 Sep 29 17:44 console-efi-141202705400000 1229 -r--r--r--. 1 root root 67 Sep 29 17:44 console-efi-141202705500000 1228 -r--r--r--. 1 root root 67 Sep 29 20:42 console-efi-141203772600000 1227 -r--r--r--. 1 root root 148 Sep 29 23:42 console-efi-141204854900000 1226 -r--r--r--. 1 root root 67 Sep 29 23:42 console-efi-141204855000000 1225 -r--r--r--. 1 root root 148 Sep 29 23:59 console-efi-141204954200000 1224 -r--r--r--. 1 root root 67 Sep 29 23:59 console-efi-141204954400000 Signed-off-by: Valdis Kletnieks Acked-by: Kees Cook Cc: stable@vger.kernel.org # 3.6+ Signed-off-by: Tony Luck