On Fri, 2012-05-11 at 07:58 +1000, Benjamin Herrenschmidt wrote:
> >
> > 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 ced
On Thu, 2012-05-10 at 14:08 -0500, Robert Jennings wrote:
> * Benjamin Herrenschmidt (b...@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 v
* Benjamin Herrenschmidt (b...@kernel.crashing.org) wrote:
> 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,
> > +
> 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 s
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->
