From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id E7EC9C28EBD for ; Sun, 9 Jun 2019 17:18:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C135B20652 for ; Sun, 9 Jun 2019 17:18:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560100712; bh=b+Z7kJ9902Wg5ePJjIatCOem4xOZ6h93vApjdrjhpb4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=FPZaeyNlooGTWQV1tvSl2kBgH+z0LYy/8VTEgsHqscCReQPhdgzIP6cKiefp1wkAm pnvifkQHT1Na5QucUx+5dIEc/Y54z21tk6L9BFCK0GYhcwbLsZIRYBK3Lb+wofQ0WC CWqOfCC0qcXR3ujes4cOacZWlthTFF7Qr9G4rD4Y= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731780AbfFIRSY (ORCPT ); Sun, 9 Jun 2019 13:18:24 -0400 Received: from mail.kernel.org ([198.145.29.99]:50052 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730714AbfFIQuR (ORCPT ); Sun, 9 Jun 2019 12:50:17 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id C3AEF205ED; Sun, 9 Jun 2019 16:50:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1560099016; bh=b+Z7kJ9902Wg5ePJjIatCOem4xOZ6h93vApjdrjhpb4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YrHUVRT69a71nX1IZwMoaRssDyVbB/+eYvzJPAjcIXquTD3MbUt8zTmhwBCiiZzLZ OYVDpTfDagoKZoa8QMPw4e3Hn46z+dqoJwNmpJlif0GzBEsIvC58GQODXBY2oxcGNN DZkMUp9kbeaYaveJAZkpx/miuQ4yyCrmX9xnh6Xc= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Paolo Abeni , "David S. Miller" , Matteo Croce Subject: [PATCH 4.14 06/35] pktgen: do not sleep with the thread lock held. Date: Sun, 9 Jun 2019 18:42:12 +0200 Message-Id: <20190609164125.879662152@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190609164125.377368385@linuxfoundation.org> References: <20190609164125.377368385@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Paolo Abeni [ Upstream commit 720f1de4021f09898b8c8443f3b3e995991b6e3a ] Currently, the process issuing a "start" command on the pktgen procfs interface, acquires the pktgen thread lock and never release it, until all pktgen threads are completed. The above can blocks indefinitely any other pktgen command and any (even unrelated) netdevice removal - as the pktgen netdev notifier acquires the same lock. The issue is demonstrated by the following script, reported by Matteo: ip -b - <<'EOF' link add type dummy link add type veth link set dummy0 up EOF modprobe pktgen echo reset >/proc/net/pktgen/pgctrl { echo rem_device_all echo add_device dummy0 } >/proc/net/pktgen/kpktgend_0 echo count 0 >/proc/net/pktgen/dummy0 echo start >/proc/net/pktgen/pgctrl & sleep 1 rmmod veth Fix the above releasing the thread lock around the sleep call. Additionally we must prevent racing with forcefull rmmod - as the thread lock no more protects from them. Instead, acquire a self-reference before waiting for any thread. As a side effect, running rmmod pktgen while some thread is running now fails with "module in use" error, before this patch such command hanged indefinitely. Note: the issue predates the commit reported in the fixes tag, but this fix can't be applied before the mentioned commit. v1 -> v2: - no need to check for thread existence after flipping the lock, pktgen threads are freed only at net exit time - Fixes: 6146e6a43b35 ("[PKTGEN]: Removes thread_{un,}lock() macros.") Reported-and-tested-by: Matteo Croce Signed-off-by: Paolo Abeni Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/core/pktgen.c | 11 +++++++++++ 1 file changed, 11 insertions(+) --- a/net/core/pktgen.c +++ b/net/core/pktgen.c @@ -3149,7 +3149,13 @@ static int pktgen_wait_thread_run(struct { while (thread_is_running(t)) { + /* note: 't' will still be around even after the unlock/lock + * cycle because pktgen_thread threads are only cleared at + * net exit + */ + mutex_unlock(&pktgen_thread_lock); msleep_interruptible(100); + mutex_lock(&pktgen_thread_lock); if (signal_pending(current)) goto signal; @@ -3164,6 +3170,10 @@ static int pktgen_wait_all_threads_run(s struct pktgen_thread *t; int sig = 1; + /* prevent from racing with rmmod */ + if (!try_module_get(THIS_MODULE)) + return sig; + mutex_lock(&pktgen_thread_lock); list_for_each_entry(t, &pn->pktgen_threads, th_list) { @@ -3177,6 +3187,7 @@ static int pktgen_wait_all_threads_run(s t->control |= (T_STOP); mutex_unlock(&pktgen_thread_lock); + module_put(THIS_MODULE); return sig; }