STRUCT PSTORE_INFO(9)

okay bestie, welcome to the struct pstore_info(9) page from the Kernel API Manual 💅 — this is the backend pstore driver structure, and we’re gonna go through every single field like it’s a group-chat screenshot. No skipping, fr fr.

🎀 NAME 🎀

struct pstore_info — backend pstore driver structure. That’s the whole vibe: it’s the struct a backend pstore driver is made of. 🫶

📜 SYNOPSIS 📜

       struct pstore_info {
           struct module   *owner;
           const char      *name;
           raw_spinlock_t buf_lock;
           char *buf;
           size_t bufsize;
           struct mutex    read_mutex;
           int flags;
           int max_reason;
           void *data;
           int (*open)(struct pstore_info *psi);
           int (*close)(struct pstore_info *psi);
           ssize_t (*read)(struct pstore_record *record);
           int (*write)(struct pstore_record *record);
           int (*write_user)(struct pstore_record *record, const char __user
       *buf);
           int (*erase)(struct pstore_record *record);
        };

🧩 Members 🧩

• owner — module which is responsible for this backend driver.
• name — name of the backend driver.
• buf_lock — spinlock to serialize access to buf.
• buf — pointer to userspace contents to write to backend.
• bufsize — size of buf available for crash dump bytes (must match smallest number of bytes available for writing to a backend entry, since compressed bytes don’t take kindly to being truncated). This one is picky on purpose, bestie.
• read_mutex — serializes open, read, close, and erase callbacks.
• flags — bitfield of frontends the backend can accept writes for.
• max_reason — Used when PSTORE_FLAGS_DMESG is set. Contains the kmsg_dump_reason enum value. KMSG_DUMP_UNDEF means "use existing kmsg_dump filtering, based on the printk.always_kmsg_dump boot param" (which is either KMSG_DUMP_OOPS when false, or KMSG_DUMP_MAX when true); see printk.always_kmsg_dump for more details.
• data — backend-private pointer passed back during callbacks.
• open — Notify backend that pstore is starting a full read of backend records. Followed by one or more read calls, and a final close.
• close — Notify backend that pstore has finished a full read of backend records. Always preceded by an open call and one or more read calls.
• read — Read next available backend record. Called after a successful open.
• write — A newly generated record needs to be written to backend storage.
• write_user — Perform a frontend write to a backend record, using a specified buffer that is coming directly from userspace, instead of the record buf.
• erase — Delete a record from backend storage. Different backends identify records differently, so entire original record is passed back to assist in identification of what the backend should remove from storage.

🌸 Description 🌸

Callbacks:

• Returns 0 on success, and non-zero on error.
• Returns 0 on success, and non-zero on error. (Though pstore will ignore the error.)
• Returns record size on success, zero when no more records are available, or negative on error.
• Returns 0 on success, and non-zero on error.
• Returns 0 on success, and non-zero on error.
• Returns 0 on success, and non-zero on error.

Yes, the return-value lines really do repeat like that. We keep the lore exact. 💀

👀 SEE ALSO 👀

• Kernel file ./include/linux/pstore.h
• struct pstore_record(9)

bye bestie 🫶 — the footer vibes are source/version ./include/linux, date October 2026, and page struct pstore_info(9). Periodt. 💖