From patchwork Thu Dec 31 10:00:12 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Gaoyan X-Patchwork-Id: 11993907 X-Patchwork-Delegate: kuba@kernel.org 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=-13.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 6086DC433E0 for ; Thu, 31 Dec 2020 10:02:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 27D08207A3 for ; Thu, 31 Dec 2020 10:02:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726463AbgLaKCL (ORCPT ); Thu, 31 Dec 2020 05:02:11 -0500 Received: from smtp.h3c.com ([60.191.123.50]:12010 "EHLO h3cspam02-ex.h3c.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726317AbgLaKCK (ORCPT ); Thu, 31 Dec 2020 05:02:10 -0500 Received: from DAG2EX07-IDC.srv.huawei-3com.com ([10.8.0.70]) by h3cspam02-ex.h3c.com with ESMTP id 0BVA0ASa034262; Thu, 31 Dec 2020 18:00:10 +0800 (GMT-8) (envelope-from gao.yanB@h3c.com) Received: from DAG2EX08-IDC.srv.huawei-3com.com (10.8.0.71) by DAG2EX07-IDC.srv.huawei-3com.com (10.8.0.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 31 Dec 2020 18:00:13 +0800 Received: from DAG2EX08-IDC.srv.huawei-3com.com ([fe80::81d1:43f5:5563:4c58]) by DAG2EX08-IDC.srv.huawei-3com.com ([fe80::81d1:43f5:5563:4c58%10]) with mapi id 15.01.2106.002; Thu, 31 Dec 2020 18:00:13 +0800 From: Gaoyan To: "paulus@samba.org" , "davem@davemloft.net" , "kuba@kernel.org" CC: "linux-ppp@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" Subject: =?utf-8?b?562U5aSNOiBbUEFUQ0hdIG5ldDogcmVtb3ZlIGRpc2NfZGF0YV9sb2Nr?= =?utf-8?b?IGluIHBwcCBsaW5lIGRpc2NpcGxpbmU=?= Thread-Topic: [PATCH] net: remove disc_data_lock in ppp line discipline Thread-Index: AQHW3OrDdljHfTEdukqMzUeudaTjxKoQ+gbQ Date: Thu, 31 Dec 2020 10:00:12 +0000 Message-ID: References: <20201228071550.15745-1-gao.yanB@h3c.com> In-Reply-To: <20201228071550.15745-1-gao.yanB@h3c.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.99.161.27] x-sender-location: DAG2 MIME-Version: 1.0 X-DNSRBL: X-MAIL: h3cspam02-ex.h3c.com 0BVA0ASa034262 Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Dear all： Could I get your comments for the updates? If I can get a reply, it will help me a lot . Thanks https://lkml.org/lkml/2020/12/28/19 ******************************* ----Original mail ----- 发件人: gaoyan (RD) 发送时间: 2020年12月28日 15:16 收件人: paulus@samba.org; davem@davemloft.net; kuba@kernel.org 抄送: linux-ppp@vger.kernel.org; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; gaoyan (RD) 主题: [PATCH] net: remove disc_data_lock in ppp line discipline In tty layer, it use tty->ldisc_sem to proect tty_ldisc_ops. So I think tty->ldisc_sem can also protect tty->disc_data; For examlpe, When cpu A is running ppp_synctty_ioctl that hold the tty->ldisc_sem, at the same time 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 | 11 ++--------- drivers/net/ppp/ppp_synctty.c | 12 ++---------- 2 files changed, 4 insertions(+), 19 deletions(-) - struct syncppp *ap; + struct syncppp *ap = tty->disc_data; - 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 diff --git a/drivers/net/ppp/ppp_async.c b/drivers/net/ppp/ppp_async.c index 29a0917a8..20b50facd 100644 --- a/drivers/net/ppp/ppp_async.c +++ b/drivers/net/ppp/ppp_async.c @@ -127,17 +127,13 @@ 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; + struct asyncppp *ap = tty->disc_data; - read_lock(&disc_data_lock); - ap = tty->disc_data; if (ap != NULL) refcount_inc(&ap->refcnt); - read_unlock(&disc_data_lock); return ap; } @@ -214,12 +210,9 @@ ppp_asynctty_open(struct tty_struct *tty) static void ppp_asynctty_close(struct tty_struct *tty) { - struct asyncppp *ap; + struct asyncppp *ap = tty->disc_data; - 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..53fb68e29 100644 --- a/drivers/net/ppp/ppp_synctty.c +++ b/drivers/net/ppp/ppp_synctty.c @@ -129,17 +129,12 @@ 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; + struct syncppp *ap = tty->disc_data; - read_lock(&disc_data_lock); - ap = tty->disc_data; if (ap != NULL) refcount_inc(&ap->refcnt); - read_unlock(&disc_data_lock); return ap; } @@ -213,12 +208,9 @@ ppp_sync_open(struct tty_struct *tty) static void ppp_sync_close(struct tty_struct *tty) {