>-----Original Message----- >From: Ulf Hansson <ulf.hansson@xxxxxxxxxx> >Sent: Thursday, December 17, 2020 10:42 PM >To: Bhaskara Budiredla <bbudiredla@xxxxxxxxxxx> >Cc: Kees Cook <keescook@xxxxxxxxxxxx>; Colin Cross ><ccross@xxxxxxxxxxx>; Tony Luck <tony.luck@xxxxxxxxx>; Sunil Kovvuri >Goutham <sgoutham@xxxxxxxxxxx>; linux-mmc@xxxxxxxxxxxxxxx; Linux >Kernel Mailing List <linux-kernel@xxxxxxxxxxxxxxx>; Christoph Hellwig ><hch@xxxxxx> >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@xxxxxxxxxxx> >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
