Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp3448948pxu; Tue, 15 Dec 2020 07:18:23 -0800 (PST) X-Google-Smtp-Source: ABdhPJz/K+XpG1i4cxPFpqAd7UZW8+32DbM3+e5rqMgFeiNaddN3h0FlUxRIJ7VmmYxvZY3MaESu X-Received: by 2002:a17:906:e206:: with SMTP id gf6mr27697419ejb.342.1608045503176; Tue, 15 Dec 2020 07:18:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608045503; cv=none; d=google.com; s=arc-20160816; b=Rem7lyjvUP1vmc6Dyzinj7V6CjudWFdsM1d5KdF4Z7WKYoMbomvxlUa+WmpVGuFgc5 YhwOQawJQ2a/DyOlhjIePtBFlBS41WTeUDFFwOnAi46Jrc9IfkStvK5RgBwvoRNieHjC /bjYqqgufEq/J2NDmgCKRo7Jqq+lZfL8a4ZZ/0HxplPCDmWkrFnGU5VWqoVswGbcsOMX zu33dfxUpmYSjv+wzXGLakVyFyH2MuIinnItvPpTIIvX9fzrOFwJX8jH4pxu3wDUL3DU 9gCVICKUFfdxT2DXj+1auGyFzhteXPUh9DyTeqbk9t+skoVwVaGXXfbY4eOrLhCqx+jZ 4fkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=DRJ8QVTyamKPayXdsKQrBvlowVit9sz8QpC8jOXIKXA=; b=uyPcNt9a3nmc9JdeUWWLRhjA0Myp+YNrjU8/jIjkYEtD3cFCnPHjdynhKDT5Us92fv /6KlJFZEX/pfeKcO4ii3tZhIRHGK6RUrOP1gpwB7obVdwKao9vAiVh4EGcERjjdUowje G2Xu1F+rK/QvSmUHJj+3VwSFPHwmjveq/GOtzPqjobAI6mPEZMDMFKh13URB/Tw9NHi3 skyOdLAQ/qEkderzkmHz5klBTgZNcHoqLuoe5CtIS9l0YMDgvsGD2Nr80fpPuoHhmtyv l2QG9TIgepdjjat+SZZrknV2VrpheTSRY+BDaa3t3yy2BfZ+BI9DAwi+Sq2E2eFVS1ea tVxw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id eb5si1013629edb.393.2020.12.15.07.17.59; Tue, 15 Dec 2020 07:18:23 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729708AbgLOPNp (ORCPT + 99 others); Tue, 15 Dec 2020 10:13:45 -0500 Received: from smtp.h3c.com ([60.191.123.56]:22665 "EHLO h3cspam01-ex.h3c.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729160AbgLOPNm (ORCPT ); Tue, 15 Dec 2020 10:13:42 -0500 Received: from DAG2EX08-IDC.srv.huawei-3com.com ([10.8.0.71]) by h3cspam01-ex.h3c.com with ESMTP id 0BFFBUSo058450; Tue, 15 Dec 2020 23:11:30 +0800 (GMT-8) (envelope-from gao.yanB@h3c.com) Received: from localhost.localdomain (10.99.212.201) by DAG2EX08-IDC.srv.huawei-3com.com (10.8.0.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 15 Dec 2020 23:11:34 +0800 From: Gao Yan To: , , CC: , , Gao Yan Subject: [PATCH] net: remove disc_data_lock in ppp line discipline Date: Tue, 15 Dec 2020 23:00:54 +0800 Message-ID: <20201215150054.570-1-gao.yanB@h3c.com> X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.99.212.201] X-ClientProxiedBy: BJSMTP02-EX.srv.huawei-3com.com (10.63.20.133) To DAG2EX08-IDC.srv.huawei-3com.com (10.8.0.71) X-DNSRBL: X-MAIL: h3cspam01-ex.h3c.com 0BFFBUSo058450 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org tty layer provide tty->ldisc_sem lock to protect tty->disc_data; For examlpe, when cpu A is running ppp_synctty_ioctl that hold the tty->ldisc_sem, so if cpu B calls ppp_synctty_close, it will wait until cpu A release tty->ldisc_sem. So I think it is unnecessary to have the disc_data_lock; cpu A cpu B tty_ioctl tty_reopen ->hold tty->ldisc_sem ->hold tty->ldisc_sem(write), failed ->ld->ops->ioctl ->wait... ->release tty->ldisc_sem ->wait...OK,hold tty->ldisc_sem ->tty_ldisc_reinit ->tty_ldisc_close ->ld->ops->close Signed-off-by: Gao Yan --- drivers/net/ppp/ppp_async.c | 5 ----- drivers/net/ppp/ppp_synctty.c | 5 ----- 2 files changed, 10 deletions(-) diff --git a/drivers/net/ppp/ppp_async.c b/drivers/net/ppp/ppp_async.c index 29a0917a8..f8cb591d6 100644 --- a/drivers/net/ppp/ppp_async.c +++ b/drivers/net/ppp/ppp_async.c @@ -127,17 +127,14 @@ static const struct ppp_channel_ops async_ops = { * FIXME: this is no longer true. The _close path for the ldisc is * now guaranteed to be sane. */ -static DEFINE_RWLOCK(disc_data_lock); static struct asyncppp *ap_get(struct tty_struct *tty) { struct asyncppp *ap; - read_lock(&disc_data_lock); ap = tty->disc_data; if (ap != NULL) refcount_inc(&ap->refcnt); - read_unlock(&disc_data_lock); return ap; } @@ -216,10 +213,8 @@ ppp_asynctty_close(struct tty_struct *tty) { struct asyncppp *ap; - write_lock_irq(&disc_data_lock); ap = tty->disc_data; tty->disc_data = NULL; - write_unlock_irq(&disc_data_lock); if (!ap) return; diff --git a/drivers/net/ppp/ppp_synctty.c b/drivers/net/ppp/ppp_synctty.c index 0f338752c..8cdf7268c 100644 --- a/drivers/net/ppp/ppp_synctty.c +++ b/drivers/net/ppp/ppp_synctty.c @@ -129,17 +129,14 @@ ppp_print_buffer (const char *name, const __u8 *buf, int count) * * FIXME: Fixed in tty_io nowadays. */ -static DEFINE_RWLOCK(disc_data_lock); static struct syncppp *sp_get(struct tty_struct *tty) { struct syncppp *ap; - read_lock(&disc_data_lock); ap = tty->disc_data; if (ap != NULL) refcount_inc(&ap->refcnt); - read_unlock(&disc_data_lock); return ap; } @@ -215,10 +212,8 @@ ppp_sync_close(struct tty_struct *tty) { struct syncppp *ap; - write_lock_irq(&disc_data_lock); ap = tty->disc_data; tty->disc_data = NULL; - write_unlock_irq(&disc_data_lock); if (!ap) return; -- 2.17.1