kernel/linux.git/drivers/mtd/mtdoops.c, branch v6.6.132

mtd: mtdoops: panic caused mtdoops to call mtdoops_erase function immediately

2022-11-07T16:08:00+00:00

The panic function disables the local interrupts, preemption, and all other processors. When the invoked mtdoops needs to erase a used page, calling schedule_work() to do it will not work. Instead, just call mtdoops_erase function immediately. Tested: ~# echo c > /proc/sysrq-trigger [ 171.654759] sysrq: Trigger a crash [ 171.658325] Kernel panic - not syncing: sysrq triggered crash ...... [ 172.406423] mtdoops: not ready 34, 35 (erase immediately) [ 172.432285] mtdoops: ready 34, 35 [ 172.435633] Rebooting in 10 seconds.. Signed-off-by: Ray Zhang Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20221010045549.2221965-4-sgzhang@google.com

mtd: mtdoops: add mtdoops_erase function and move mtdoops_inc_counter to after it

2022-11-07T16:07:59+00:00

Preparing for next patch with minimal code difference, add mtdoops_erase function and move mtdoops_inc_counter to after it, with no functional change. Signed-off-by: Ray Zhang Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20221010045549.2221965-3-sgzhang@google.com

mtd: mtdoops: change printk() to counterpart pr_ functions

2022-11-07T16:07:59+00:00

To comply with latest kernel code requirement, change printk() to counterpart pr_ functions in mtdoops driver: - change printk(INFO) to pr_info() - change printk(DEBUG) to pr_debug() - change printk(WARNING) to pr_warn() - change printk(ERR) to pr_err() Note that only if dynamic debugging is enabled or DEBUG is defined, printk(KERN_DEBUG) and pr_debug() are equivalent; Otherwise pr_debug() is no-op, causing different behavior. Signed-off-by: Ray Zhang Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20221010045549.2221965-2-sgzhang@google.com

mtd: mtdoops: Add a timestamp to the mtdoops header.

2022-04-26T07:27:12+00:00

On some systems, the oops only has relative time from boot. Signed-off-by: Jean-Marc Eurin Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220425160927.3823016-1-jmeurin@google.com

mtd: mtdoops: Create a header structure for the saved mtdoops.

2022-04-26T07:27:07+00:00

Create a dump header to enable the addition of fields without having to modify the rest of the code. Reported-by: kernel test robot Signed-off-by: Jean-Marc Eurin Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220421234244.2172003-3-jmeurin@google.com

mtd: mtdoops: Fix the size of the header read buffer.

2022-04-26T07:27:05+00:00

The read buffer size depends on the MTDOOPS_HEADER_SIZE. Tested: Changed the header size, it doesn't panic, header is still read/written correctly. Signed-off-by: Jean-Marc Eurin Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20220421234244.2172003-2-jmeurin@google.com

mtd: mtdoops: remove unnecessary oom message

2021-06-11T18:43:46+00:00

Fixes scripts/checkpatch.pl warning: WARNING: Possible unnecessary 'out of memory' message Remove it can help us save a bit of memory. Signed-off-by: Zhen Lei Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20210610021201.15076-1-thunder.leizhen@huawei.com

printk: introduce a kmsg_dump iterator

2021-03-08T10:43:27+00:00

Rather than storing the iterator information in the registered kmsg_dumper structure, create a separate iterator structure. The kmsg_dump_iter structure can reside on the stack of the caller, thus allowing lockless use of the kmsg_dump functions. Update code that accesses the kernel logs using the kmsg_dumper structure to use the new kmsg_dump_iter structure. For kmsg_dumpers, this also means adding a call to kmsg_dump_rewind() to initialize the iterator. All this is in preparation for removal of @logbuf_lock. Signed-off-by: John Ogness Reviewed-by: Kees Cook # pstore Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210303101528.29901-13-john.ogness@linutronix.de

mtd: mtdoops: synchronize kmsg_dumper

2021-03-08T10:42:46+00:00

The kmsg_dumper can be called from any context and CPU, possibly from multiple CPUs simultaneously. Since the writing of the buffer can occur from a later scheduled work queue, the oops buffer must be protected against simultaneous dumping. Use an atomic bit to mark when the buffer is protected. Release the protection in between setting the buffer and the actual writing in order for a possible panic (immediate write) to be written during the scheduling of a previous oops (delayed write). An atomic bit (rather than a spinlock) was chosen so that no scheduling or preemption side-effects would be introduced. The MTD kmsg_dumper may dump directly or it may be delayed (via scheduled work). Depending on the context, different MTD callbacks are used. For example, mtd_write() expects to be called in a non-atomic context and may take a mutex. Signed-off-by: John Ogness Reviewed-by: Petr Mladek Signed-off-by: Petr Mladek Link: https://lore.kernel.org/r/20210303101528.29901-3-john.ogness@linutronix.de

mtd: mtdoops: Don't write panic data twice

2020-09-07T12:22:12+00:00

If calling mtdoops_write, don't also schedule work to be done later. Although this appears to not be causing an issue, possibly because the scheduled work will never get done, it is confusing. Fixes: 016c1291ce70 ("mtd: mtdoops: do not use mtd->panic_write directly") Signed-off-by: Mark Tomlinson Signed-off-by: Miquel Raynal Link: https://lore.kernel.org/linux-mtd/20200903034217.23079-1-mark.tomlinson@alliedtelesis.co.nz