From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Robert Jennings <rcj@linux.vnet.ibm.com> Cc: Kent Yoder <key@linux.vnet.ibm.com>, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org, linuxppc-dev@lists.ozlabs.org Subject: Re: [PATCH v3 03/17] powerpc: Add PFO support to the VIO bus Date: Fri, 11 May 2012 07:58:18 +1000 [thread overview] Message-ID: <1336687098.3881.63.camel@pasglop> (raw) In-Reply-To: <20120510190835.GB12304@linux.vnet.ibm.com> On Thu, 2012-05-10 at 14:08 -0500, Robert Jennings wrote: > * Benjamin Herrenschmidt (benh@kernel.crashing.org) wrote: > > Is this meant to be called in atomic context ? If not, maybe it should > > at the very least do a cond_resched() ? > > > > Else, what about ceding the processor ? Or at the very least reducing > > the thread priority for a bit ? > > > > Shouldn't we also enforce to always have a timeout ? IE. Something like > > 30s or so if nothing specified to avoid having the kernel just hard > > lock... > > > > In general I don't like that sort of synchronous code, I'd rather return > > the busy status up the chain which gives a chance to the caller to take > > more appropriate measures depending on what it's doing, but that really > > depends what you use that synchronous call for. I suppose if it's for > > configuration type operations, it's ok... > > This function is called in atomic context, it is used by PFO-type device > drivers to perform operations with the nest accelerator unit (like > crypto acceleration). > > Having the timeout and retries in this function is the wrong thing to do. > We'll resubmit this without the loop and the caller will be responsible for > retrying the operations. > > I would rather have the caller cede the processor or alter thread > priority where appropriate than doing that in this function. I don't > think this should be done in this crypto driver. That sounds right indeed... as long as the upper crypto layer has a concept of "try again later"... if it doesn't it will result in random funny failures :-) Cheers, Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> To: Robert Jennings <rcj@linux.vnet.ibm.com> Cc: Kent Yoder <key@linux.vnet.ibm.com>, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org Subject: Re: [PATCH v3 03/17] powerpc: Add PFO support to the VIO bus Date: Fri, 11 May 2012 07:58:18 +1000 [thread overview] Message-ID: <1336687098.3881.63.camel@pasglop> (raw) In-Reply-To: <20120510190835.GB12304@linux.vnet.ibm.com> On Thu, 2012-05-10 at 14:08 -0500, Robert Jennings wrote: > * Benjamin Herrenschmidt (benh@kernel.crashing.org) wrote: > > Is this meant to be called in atomic context ? If not, maybe it should > > at the very least do a cond_resched() ? > > > > Else, what about ceding the processor ? Or at the very least reducing > > the thread priority for a bit ? > > > > Shouldn't we also enforce to always have a timeout ? IE. Something like > > 30s or so if nothing specified to avoid having the kernel just hard > > lock... > > > > In general I don't like that sort of synchronous code, I'd rather return > > the busy status up the chain which gives a chance to the caller to take > > more appropriate measures depending on what it's doing, but that really > > depends what you use that synchronous call for. I suppose if it's for > > configuration type operations, it's ok... > > This function is called in atomic context, it is used by PFO-type device > drivers to perform operations with the nest accelerator unit (like > crypto acceleration). > > Having the timeout and retries in this function is the wrong thing to do. > We'll resubmit this without the loop and the caller will be responsible for > retrying the operations. > > I would rather have the caller cede the processor or alter thread > priority where appropriate than doing that in this function. I don't > think this should be done in this crypto driver. That sounds right indeed... as long as the upper crypto layer has a concept of "try again later"... if it doesn't it will result in random funny failures :-) Cheers, Ben.
next prev parent reply other threads:[~2012-05-10 21:58 UTC|newest] Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-12 15:00 [PATCH v3 00/17] Platform Facilities Option and crypto accelerators Kent Yoder 2012-04-12 15:00 ` Kent Yoder 2012-04-12 15:04 ` [PATCH v3 01/17] powerpc: Add new hvcall constants to support PFO Kent Yoder 2012-04-12 15:04 ` Kent Yoder 2012-04-12 15:04 ` [PATCH v3 02/17] powerpc: Add pseries update notifier for OFDT prop changes Kent Yoder 2012-04-12 15:04 ` Kent Yoder 2012-04-12 15:08 ` [PATCH v3 03/17] powerpc: Add PFO support to the VIO bus Kent Yoder 2012-04-12 15:08 ` Kent Yoder 2012-05-01 3:06 ` Benjamin Herrenschmidt 2012-05-01 3:06 ` Benjamin Herrenschmidt 2012-05-01 4:10 ` Benjamin Herrenschmidt 2012-05-01 4:10 ` Benjamin Herrenschmidt 2012-05-10 19:08 ` Robert Jennings 2012-05-10 19:08 ` Robert Jennings 2012-05-10 21:58 ` Benjamin Herrenschmidt [this message] 2012-05-10 21:58 ` Benjamin Herrenschmidt 2012-05-14 0:32 ` Benjamin Herrenschmidt 2012-05-14 0:32 ` Benjamin Herrenschmidt 2012-05-14 20:59 ` [PATCH v4 06/17] powerpc: crypto: nx driver code supporting nx encryption Kent Yoder 2012-05-14 20:59 ` Kent Yoder 2012-05-14 21:05 ` [PATCH v4 07/17] powerpc: crypto: AES-CBC mode routines for " Kent Yoder 2012-05-14 21:05 ` Kent Yoder 2012-05-14 21:05 ` [PATCH v4 08/17] powerpc: crypto: AES-CCM " Kent Yoder 2012-05-14 21:05 ` Kent Yoder 2012-05-14 21:05 ` [PATCH v4 09/17] powerpc: crypto: AES-CTR " Kent Yoder 2012-05-14 21:05 ` Kent Yoder 2012-05-14 21:05 ` [PATCH v4 10/17] powerpc: crypto: AES-ECB " Kent Yoder 2012-05-14 21:05 ` Kent Yoder 2012-05-14 21:05 ` [PATCH v4 11/17] powerpc: crypto: AES-GCM " Kent Yoder 2012-05-14 21:05 ` Kent Yoder 2012-05-14 21:06 ` [PATCH v4 12/17] powerpc: crypto: AES-XCBC " Kent Yoder 2012-05-14 21:06 ` Kent Yoder 2012-05-14 21:06 ` [PATCH v4 13/17] powerpc: crypto: SHA256 hash " Kent Yoder 2012-05-14 21:06 ` Kent Yoder 2012-05-14 21:06 ` [PATCH v4 14/17] powerpc: crypto: SHA512 " Kent Yoder 2012-05-14 21:06 ` Kent Yoder 2012-04-12 15:08 ` [PATCH v3 04/17] hwrng: pseries - PFO-based hwrng driver Kent Yoder 2012-04-12 15:08 ` Kent Yoder 2012-04-12 15:17 ` [PATCH v3 05/17] pseries: Enabled the PFO-based RNG accelerator Kent Yoder 2012-04-12 15:17 ` Kent Yoder 2012-04-12 15:23 ` [PATCH v3 06/17] powerpc: crypto: nx driver code supporting nx encryption Kent Yoder 2012-04-12 15:23 ` Kent Yoder 2012-04-12 15:24 ` [PATCH v3 07/17] powerpc: crypto: AES-CBC mode routines for " Kent Yoder 2012-04-12 15:24 ` Kent Yoder 2012-04-12 15:28 ` [PATCH v3 08/17] powerpc: crypto: AES-CCM " Kent Yoder 2012-04-12 15:28 ` Kent Yoder 2012-04-12 15:31 ` [PATCH v3 09/17] powerpc: crypto: AES-CTR " Kent Yoder 2012-04-12 15:31 ` Kent Yoder 2012-04-12 15:31 ` [PATCH v3 10/17] powerpc: crypto: AES-ECB " Kent Yoder 2012-04-12 15:31 ` Kent Yoder 2012-04-12 15:33 ` [PATCH v3 11/17] powerpc: crypto: AES-GCM " Kent Yoder 2012-04-12 15:33 ` Kent Yoder 2012-04-12 15:38 ` [PATCH v3 12/17] powerpc: crypto: AES-XCBC " Kent Yoder 2012-04-12 15:38 ` Kent Yoder 2012-04-12 15:38 ` [PATCH v3 13/17] powerpc: crypto: SHA256 hash " Kent Yoder 2012-04-12 15:38 ` Kent Yoder 2012-04-12 15:38 ` [PATCH v3 14/17] powerpc: crypto: SHA512 " Kent Yoder 2012-04-12 15:38 ` Kent Yoder 2012-04-12 15:38 ` [PATCH v3 15/17] powerpc: crypto: debugfs routines and docs for the nx device driver Kent Yoder 2012-04-12 15:38 ` Kent Yoder 2012-04-12 15:39 ` [PATCH v3 16/17] powerpc: crypto: Build files " Kent Yoder 2012-04-12 15:39 ` Kent Yoder 2012-04-12 15:39 ` [PATCH v3 17/17] powerpc: crypto: enable the PFO-based encryption device Kent Yoder 2012-04-12 15:39 ` Kent Yoder
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1336687098.3881.63.camel@pasglop \ --to=benh@kernel.crashing.org \ --cc=key@linux.vnet.ibm.com \ --cc=linux-crypto@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=rcj@linux.vnet.ibm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.