From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1750941AbeAUQLX (ORCPT <rfc822;w@1wt.eu>);
        Sun, 21 Jan 2018 11:11:23 -0500
Received: from mail.kernel.org ([198.145.29.99]:59690 "EHLO mail.kernel.org"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1750793AbeAUQLW (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Sun, 21 Jan 2018 11:11:22 -0500
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1B2E521715
Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org
Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=frederic@kernel.org
Date: Sun, 21 Jan 2018 17:11:17 +0100
From: Frederic Weisbecker <frederic@kernel.org>
To: Pavan Kondeti <pkondeti@codeaurora.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
        Levin Alexander <alexander.levin@verizon.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Mauro Carvalho Chehab <mchehab@s-opensource.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Hannes Frederic Sowa <hannes@stressinduktion.org>,
        "Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
        Wanpeng Li <wanpeng.li@hotmail.com>, Dmitry Safonov <dima@arista.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        Andrew Morton <akpm@linux-foundation.org>,
        Paolo Abeni <pabeni@redhat.com>, Radu Rendec <rrendec@arista.com>,
        Ingo Molnar <mingo@kernel.org>,
        Stanislaw Gruszka <sgruszka@redhat.com>,
        Rik van Riel <riel@redhat.com>, Eric Dumazet <edumazet@google.com>,
        David Miller <davem@davemloft.net>
Subject: Re: [RFC PATCH 2/4] softirq: Per vector deferment to workqueue
Message-ID: <20180121161114.GA2879@lerouge>
References: <1516376774-24076-1-git-send-email-frederic@kernel.org>
 <1516376774-24076-3-git-send-email-frederic@kernel.org>
 <20180120084139.GA8395@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180120084139.GA8395@codeaurora.org>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sat, Jan 20, 2018 at 02:11:39PM +0530, Pavan Kondeti wrote:

Hi Pavan,


> I have couple questions/comments.
> 
> (1) Since the work is queued on a bounded per-cpu worker, we may run
> into a deadlock if a TASKLET is killed from another work running on
> the same bounded per-cpu worker.
> 
> For example,
> 
> (1) Schedule a TASKLET on CPU#0 from IRQ.
> (2) Another IRQ comes on the same CPU and we queue a work to kill
> the TASKLET. 
> (3) The TASKLET vector is deferred to workqueue.
> (4) We run the TASKLET kill work and wait for the TASKLET to finish,
> which won't happen.
> 
> We can fix this by queueing the TASKLET kill work on an unbounded
> workqueue so that this runs in parallel with TASKLET vector work.
> 
> Just wanted to know if we have to be aware of this *condition*.

But IIRC the workqueues have several workers per CPU so the tasklet to
be killed can run while the tasklet killer yields.

> 
> (2) Ksoftirqd thread gets parked when a CPU is hotplugged out. So
> there is a gaurantee that the softirq handling never happens on
> another CPU. Where as a bounded worker gets detached and the queued
> work can run on another CPU. I guess, some special handling is
> needed to handle hotplug.

Good catch. Funny, I worried a bit about CPU hotplug but I assumed
the pending CPU-bound worklets would be simply sync'ed before CPU gets down.

Breaking their CPU-bound properties doesn't look sane to me.

Anyway, I'll need to make a CPU hotplug hook.

Thanks for reporting that!