lkml.org 
[lkml]   [2016]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Interesting csd deadlock on ARC
On Wed, Feb 24, 2016 at 10:21:25AM +0530, Vineet Gupta wrote:
> >> What I actually meant was is it OK for irq_work_queue_on() to be called locally
> >> (is this a sched bug/optimization(. Further if it is OK to be called, does it need
> >> to do behave more like irq_work_queue() i.e. call arch_irq_work_raise() or
> >> arch_send_call_function_single_ipi() is expected to handle sending IPI to self !
> >
> > Right, so I'm not actually sure we started out with this requirement.
> > But you're not the first to run into this, see:
> >
> > lkml.kernel.org/r/CAJZ5v0gLankSuziQq25qTCyNqeOX43yD9jnJu_XXwbdyajfmKg@mail.gmail.com
> >
> > Initially I think irq_work_queue_on() was only used remotely, but I
> > think it makes sense to allow the current cpu, esp. since people seem to
> > be using it like that.
>
> So it seems Russell's questions in the thread above stands still. IMO we need to
> massage irq_work_queue_on() to handle the case of called for local cpu. This will
> automatically take care of CONFIG_SMP kernel running on UP hardware.

Hmm, I missed that there was still an open question.

Afaict the only thing that needs doing to the generic code is drop the
CONFIG_SMP guard, no?

\
 
 \ /
  Last update: 2016-02-25 15:41    [W:0.101 / U:0.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site