linux-kernel - Re: [RFC v4 0/3] pstore/rom: new support logger for block devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 Jan 2019 15:03:41 +0800
From:   廖威雄 <liaoweixiong@...winnertech.com>
To:     "Luck, Tony" <tony.luck@...el.com>,
        Kees Cook <keescook@...omium.org>,
        Anton Vorontsov <anton@...msg.org>,
        Colin Cross <ccross@...roid.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v4 0/3] pstore/rom: new support logger for block devices

hi Tony:
On 2019-01-04 01:18, Luck, Tony wrote:
> I'm curious why you call this "pstore/rom" rather than the more descriptive "pstore/block".
Because there is "pstore/ram", so i name it as "pstore/rom".
It's nice to rename it "pstore/block", i will change it in next version
of patch.
> 
> It looks to be a really good idea.
Should i add "Acked-by" in next version of patch?
I have little experience in sending patch to upstream linux.
> 
> I think you need to document how the "write" function for the block device must be written.
> Since pstore calls this at "panic" time, the write path:
> 
> + Cannot allocate any memory
> + Must be polled, not interrupt driven
> + Cannot take any locks that may be held by regular code
> + ... perhaps other restrictions that I can't think of right now
> 
> The memory allocation restriction is likely easy to get around. Just allocate anything
> you need at pstore "init" time rather than waiting until the panic.
>I will provide a documemt for it in next version of patch.
> -Tony
>