linux-kernel - RE: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on pstore/blk

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]

Message-ID: <CY4PR1801MB2070C05E828C5D12544183ADDEC30@CY4PR1801MB2070.namprd18.prod.outlook.com>
Date:   Fri, 18 Dec 2020 04:02:14 +0000
From:   Bhaskara Budiredla <bbudiredla@...vell.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>
CC:     Kees Cook <keescook@...omium.org>,
        Colin Cross <ccross@...roid.com>,
        "Tony Luck" <tony.luck@...el.com>,
        Sunil Kovvuri Goutham <sgoutham@...vell.com>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
        Christoph Hellwig <hch@....de>
Subject: RE: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on
 pstore/blk



>-----Original Message-----
>From: Ulf Hansson <ulf.hansson@...aro.org>
>Sent: Thursday, December 17, 2020 10:42 PM
>To: Bhaskara Budiredla <bbudiredla@...vell.com>
>Cc: Kees Cook <keescook@...omium.org>; Colin Cross
><ccross@...roid.com>; Tony Luck <tony.luck@...el.com>; Sunil Kovvuri
>Goutham <sgoutham@...vell.com>; linux-mmc@...r.kernel.org; Linux
>Kernel Mailing List <linux-kernel@...r.kernel.org>; Christoph Hellwig
><hch@....de>
>Subject: Re: [EXT] Re: [PATCH 1/2] mmc: Support kmsg dumper based on
>pstore/blk
>
>On Thu, 17 Dec 2020 at 12:36, Bhaskara Budiredla <bbudiredla@...vell.com>
>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 the device belonging to the mmc card can be runtime
>> >> >suspended too. So if that is the case, we should return an error too?
>> >> >
>> >>
>> >> Yes, same here.
>> >>
>>
>> Please comment if returning error is sufficient here or can there be
>> an attempt to wake the device through either of the atomic activation calls:
>> pm_runtime_get(),  pm_request_resume()?
>
>Hmm, I would start with playing with the below. mmc_claim_host supports
>also nested claims.
>
>mmc_claim_host(host)  - this will call pm_runtime_get_sync(host)
>mmc_get_card(card, NULL) - this will call can
>pm_runtime_get_sync(card)) and also try to claim the host
>

As you suggested I am creating a parallel path that avoids wait queue 
to claim the host. The *_sync()* routines could sleep, I can't use them
as part of panic write. 


>Kind regards
>Uffe

Thanks,
Bhaskara