All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kent Yoder <key@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
	rcj@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH v3 03/17] powerpc: Add PFO support to the VIO bus
Date: Tue, 01 May 2012 13:06:43 +1000	[thread overview]
Message-ID: <1335841603.3621.8.camel@pasglop> (raw)
In-Reply-To: <1334243302.18090.10.camel@key-ThinkPad-W510>

Hrm... I don't like that much:

> +	if (op->timeout)
> +		deadline = jiffies + msecs_to_jiffies(op->timeout);
> +
> +	while (true) {
> +		hret = plpar_hcall_norets(H_COP, op->flags,
> +				vdev->resource_id,
> +				op->in, op->inlen, op->out,
> +				op->outlen, op->csbcpb);
> +
> +		if (hret == H_SUCCESS ||
> +		    (hret != H_NOT_ENOUGH_RESOURCES &&
> +		     hret != H_BUSY && hret != H_RESOURCE) ||
> +		    (op->timeout && time_after(deadline, jiffies)))
> +			break;
> +
> +		dev_dbg(dev, "%s: hcall ret(%ld), retrying.\n", __func__, hret);
> +	}
> +

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...

Cheers,
Ben.

WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Kent Yoder <key@linux.vnet.ibm.com>
Cc: rcj@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: Tue, 01 May 2012 13:06:43 +1000	[thread overview]
Message-ID: <1335841603.3621.8.camel@pasglop> (raw)
In-Reply-To: <1334243302.18090.10.camel@key-ThinkPad-W510>

Hrm... I don't like that much:

> +	if (op->timeout)
> +		deadline = jiffies + msecs_to_jiffies(op->timeout);
> +
> +	while (true) {
> +		hret = plpar_hcall_norets(H_COP, op->flags,
> +				vdev->resource_id,
> +				op->in, op->inlen, op->out,
> +				op->outlen, op->csbcpb);
> +
> +		if (hret == H_SUCCESS ||
> +		    (hret != H_NOT_ENOUGH_RESOURCES &&
> +		     hret != H_BUSY && hret != H_RESOURCE) ||
> +		    (op->timeout && time_after(deadline, jiffies)))
> +			break;
> +
> +		dev_dbg(dev, "%s: hcall ret(%ld), retrying.\n", __func__, hret);
> +	}
> +

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...

Cheers,
Ben.

  reply	other threads:[~2012-05-01  3:09 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 [this message]
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
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=1335841603.3621.8.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 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.