linux-toradex.git/include/linux/pstore_ram.h, branch v5.1-rc4

pstore: Map PSTORE_TYPE_* to strings

2018-12-04T00:52:35+00:00

In later patches we will need to map types to names, so create a
constant table for that which can also be used in different parts of
old and new code. This saves the type in the PRZ which will be useful
in later patches.

Instead of having an explicit PSTORE_TYPE_UNKNOWN, just use ..._MAX.

This includes removing the now redundant filename templates which can use
a single format string. Also, there's no reason to limit the "is it still
compressed?" test to only PSTORE_TYPE_DMESG when building the pstorefs
filename. Records are zero-initialized, so a backend would need to have
explicitly set compressed=1.

Signed-off-by: Joel Fernandes (Google) 
Co-developed-by: Kees Cook 
Signed-off-by: Kees Cook

pstore/ram: Add kern-doc for struct persistent_ram_zone

2018-12-04T00:52:35+00:00

The struct persistent_ram_zone wasn't well documented. This adds kern-doc
for it.

Signed-off-by: Kees Cook

pstore: Avoid duplicate call of persistent_ram_zap()

2018-12-04T00:52:35+00:00

When initialing a prz, if invalid data is found (no PERSISTENT_RAM_SIG),
the function call path looks like this:

ramoops_init_prz ->
    persistent_ram_new -> persistent_ram_post_init -> persistent_ram_zap
    persistent_ram_zap

As we can see, persistent_ram_zap() is called twice.
We can avoid this by adding an option to persistent_ram_new(), and
only call persistent_ram_zap() when it is needed.

Signed-off-by: Peng Wang 
[kees: minor tweak to exit path and commit log]
Signed-off-by: Kees Cook

pstore/ram: Clarify resource reservation labels

2018-10-22T14:11:58+00:00

When ramoops reserved a memory region in the kernel, it had an unhelpful
label of "persistent_memory". When reading /proc/iomem, it would be
repeated many times, did not hint that it was ramoops in particular,
and didn't clarify very much about what each was used for:

400000000-407ffffff : Persistent Memory (legacy)
  400000000-400000fff : persistent_memory
  400001000-400001fff : persistent_memory
...
  4000ff000-4000fffff : persistent_memory

Instead, this adds meaningful labels for how the various regions are
being used:

400000000-407ffffff : Persistent Memory (legacy)
  400000000-400000fff : ramoops:dump(0/252)
  400001000-400001fff : ramoops:dump(1/252)
...
  4000fc000-4000fcfff : ramoops:dump(252/252)
  4000fd000-4000fdfff : ramoops:console
  4000fe000-4000fe3ff : ramoops:ftrace(0/3)
  4000fe400-4000fe7ff : ramoops:ftrace(1/3)
  4000fe800-4000febff : ramoops:ftrace(2/3)
  4000fec00-4000fefff : ramoops:ftrace(3/3)
  4000ff000-4000fffff : ramoops:pmsg

Signed-off-by: Kees Cook 
Reviewed-by: Joel Fernandes (Google) 
Tested-by: Sai Prakash Ranjan 
Tested-by: Guenter Roeck

pstore/ram: Do not use stack VLA for parity workspace

2018-03-07T20:47:06+00:00

Instead of using a stack VLA for the parity workspace, preallocate a
memory region. The preallocation is done to keep from needing to perform
allocations during crash dump writing, etc. This also fixes a missed
release of librs on free.

Signed-off-by: Kees Cook

ramoops: Split ftrace buffer space into per-CPU zones

2016-11-16T00:34:26+00:00

If the RAMOOPS_FLAG_FTRACE_PER_CPU flag is passed to ramoops pdata, split
the ftrace space into multiple zones depending on the number of CPUs.

This speeds up the performance of function tracing by about 280% in my
tests as we avoid the locking. The trade off being lesser space available
per CPU. Let the ramoops user decide which option they want based on pdata
flag.

Signed-off-by: Joel Fernandes 
[kees: added max_ftrace_cnt to track size, added DT logic and docs]
Signed-off-by: Kees Cook

pstore: Allow prz to control need for locking

2016-11-16T00:34:25+00:00

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

pstore: Make spinlock per zone instead of global

2016-11-11T18:35:37+00:00

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

pstore/pmsg: drop bounce buffer

2016-09-08T22:01:10+00:00

Removing a bounce buffer copy operation in the pmsg driver path is
always better. We also gain in overall performance by not requesting
a vmalloc on every write as this can cause precious RT tasks, such
as user facing media operation, to stall while memory is being
reclaimed. Added a write_buf_user to the pstore functions, a backup
platform write_buf_user that uses the small buffer that is part of
the instance, and implemented a ramoops write_buf_user that only
supports PSTORE_TYPE_PMSG.

Signed-off-by: Mark Salyzyn 
Signed-off-by: Kees Cook

pstore: Add support for 64 Bit address space

2016-03-10T17:43:36+00:00

Some architectures have their reserved RAM in 64 Bit address space.
Therefore convert mem_address module parameter to ullong.

Signed-off-by: Wladislav Wiebe 
Acked-by: Kees Cook 
Signed-off-by: Tony Luck