On Wed, Dec 16, 2020 at 11:44:26AM +0100, Ulf Hansson wrote:
> In any case, I didn't catch *why* pstore needs to force block device
> drivers to implement specific pstore hooks to support the pstore file
> system. I don't think this is the way it should work, for many
For panic, pstore must avoid
ject: Re: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on
>pstore/blk
>
>On Thu, 17 Dec 2020 at 12:36, Bhaskara Budiredla
>wrote:
>>
>>
>> [...]
>>
>> >> >> An extra check can be added to see if host was runtime suspended
>> &
On Thu, 17 Dec 2020 at 12:36, Bhaskara Budiredla wrote:
>
>
> [...]
>
> >> >> An extra check can be added to see if host was runtime suspended
> >> >> ahead of panic write attempt.
> >> >
> >> >What if that is the case, should we just return an error?
> >> >
> >> Yes.
> >>
> >> >Moreover, even
[...]
>> >> An extra check can be added to see if host was runtime suspended
>> >> ahead of panic write attempt.
>> >
>> >What if that is the case, should we just return an error?
>> >
>> Yes.
>>
>> >Moreover, even the device belonging to the mmc card can be runtime
>> >suspended too. So if that
[...]
> >>
> >> Agree. Seems I need to create an alternate path to forcefully gain
> >> access to the host for the case of panic write. As you pointed out
> >> mmc_claim_host(), mmc_release_host() and runtime PM can create issues.
> >>
> >> >The question is, can/should we rely on mmc_claim_host()
On Tue, 15 Dec 2020 at 21:37, Kees Cook wrote:
>
> On Tue, Dec 15, 2020 at 12:42:58PM +0100, Ulf Hansson wrote:
> > In principle, for non atomic path, I would rather see that the pstore
> > file system should be able to be mounted on top of any generic block
> > device partition - without
ject: Re: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on
>pstore/blk
>
>[...]
>
>> >> >
>> >> >It looks like the above I/O read/write interface for pstore is
>> >> >intended to be used when the platform is up and running and not
[...]
> >> >
> >> >It looks like the above I/O read/write interface for pstore is
> >> >intended to be used when the platform is up and running and not during a
> >panic, correct?
> >> >
> >> >If so, I don't get why it can't use the regular block interface, as
> >> >any other file system does,
On Tue, Dec 15, 2020 at 12:42:58PM +0100, Ulf Hansson wrote:
> In principle, for non atomic path, I would rather see that the pstore
> file system should be able to be mounted on top of any generic block
> device partition - without requiring the block device driver to
> implement specific pstore
PM
>> >To: Bhaskara Budiredla
>> >Cc: Kees Cook ; Colin Cross
>> >; Tony Luck ; Sunil Kovvuri
>> >Goutham ; linux-...@vger.kernel.org; Linux
>> >Kernel Mailing List
> >Goutham ; linux-...@vger.kernel.org; Linux
> >Kernel Mailing List ; Christoph Hellwig
> >
> >Subject: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on
> >pstore/blk
> >
> >External Email
> >
> >-
>-Original Message-
>From: Ulf Hansson
>Sent: Friday, December 11, 2020 5:02 PM
>To: Bhaskara Budiredla
>Cc: Kees Cook ; Colin Cross
>; Tony Luck ; Sunil Kovvuri
>Goutham ; linux-...@vger.kernel.org; Linux
>Kernel Mailing List ; Christoph Hellwig
>
>Subj
12 matches
Mail list logo
