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: 32+ 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:04 ` [PATCH v3 01/17] powerpc: Add new hvcall constants to support PFO 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:08 ` [PATCH v3 03/17] powerpc: Add PFO support to the VIO bus Kent Yoder
2012-05-01 3:06 ` Benjamin Herrenschmidt
2012-05-01 4:10 ` Benjamin Herrenschmidt
2012-05-10 19:08 ` Robert Jennings
2012-05-10 21:58 ` Benjamin Herrenschmidt [this message]
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 21:05 ` [PATCH v4 07/17] powerpc: crypto: AES-CBC mode routines for " Kent Yoder
2012-05-14 21:05 ` [PATCH v4 08/17] powerpc: crypto: AES-CCM " Kent Yoder
2012-05-14 21:05 ` [PATCH v4 09/17] powerpc: crypto: AES-CTR " Kent Yoder
2012-05-14 21:05 ` [PATCH v4 10/17] powerpc: crypto: AES-ECB " Kent Yoder
2012-05-14 21:05 ` [PATCH v4 11/17] powerpc: crypto: AES-GCM " Kent Yoder
2012-05-14 21:06 ` [PATCH v4 12/17] powerpc: crypto: AES-XCBC " Kent Yoder
2012-05-14 21:06 ` [PATCH v4 13/17] powerpc: crypto: SHA256 hash " Kent Yoder
2012-05-14 21:06 ` [PATCH v4 14/17] powerpc: crypto: SHA512 " Kent Yoder
2012-04-12 15:08 ` [PATCH v3 04/17] hwrng: pseries - PFO-based hwrng driver Kent Yoder
2012-04-12 15:17 ` [PATCH v3 05/17] pseries: Enabled the PFO-based RNG accelerator 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:24 ` [PATCH v3 07/17] powerpc: crypto: AES-CBC mode routines for " Kent Yoder
2012-04-12 15:28 ` [PATCH v3 08/17] powerpc: crypto: AES-CCM " Kent Yoder
2012-04-12 15:31 ` [PATCH v3 09/17] powerpc: crypto: AES-CTR " Kent Yoder
2012-04-12 15:31 ` [PATCH v3 10/17] powerpc: crypto: AES-ECB " Kent Yoder
2012-04-12 15:33 ` [PATCH v3 11/17] powerpc: crypto: AES-GCM " Kent Yoder
2012-04-12 15:38 ` [PATCH v3 12/17] powerpc: crypto: AES-XCBC " Kent Yoder
2012-04-12 15:38 ` [PATCH v3 13/17] powerpc: crypto: SHA256 hash " Kent Yoder
2012-04-12 15:38 ` [PATCH v3 14/17] powerpc: crypto: SHA512 " 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:39 ` [PATCH v3 16/17] powerpc: crypto: Build files " Kent Yoder
2012-04-12 15:39 ` [PATCH v3 17/17] powerpc: crypto: enable the PFO-based encryption device 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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).