Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp11858399pxu; Fri, 1 Jan 2021 01:07:09 -0800 (PST) X-Google-Smtp-Source: ABdhPJyAcmg4Wf5YMqkcEEH+0/60kdKrudiZtx3ucjIUTdgyKLNuxnGoKUJhP9S3W7Ggm/y4H0w6 X-Received: by 2002:a05:6402:1d15:: with SMTP id dg21mr57621840edb.280.1609492029059; Fri, 01 Jan 2021 01:07:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609492029; cv=none; d=google.com; s=arc-20160816; b=QbaTDm7py2Ir8XcW9JrWRpgsJpn9BqFsc7tKrRildx+iY90I3NiMD5ZZ4DSEhVZfJN 6kB7ikOclJX+6OoNnCYCF8PJCJZayalzM1s70/rJADMRu9I8CiIZ0SE24WKoDvuN0WaH 0TgAxLQpeOK9uMINPg2LyoGfqbaXi1wvORb2RNOplE6CDdzi39ORUPPp3T3/zvaBvOD1 NNpe/+KFmlRtUox3qQNb3t1/A2u/pO8xy/Y1wtMmz8uX4Iy09nQKzrJ76sivSVaF7SxM qLUObpGOA0UEQ+iuMTKTD+29OCsLsWpk3ZpN29AnKT27kVeXu4w/r5BZXtB5jO71n5OM zp/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:content-transfer-encoding :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=yb+Kbhv3UrhFUe5pi8VuhnveFwRMnCVfwfRSALqV5jk=; b=0YNn2ONxMQIbv8sDHvi2dnXQAwJNWrG4tgwq5/jnYRSV5+GwOHYXDexJOjVvGSJLJv bpxpYQr753mHHSK/nCpwagXpzN4bDgdEIdnJHX2Z1lkm195YFIP32+ChO6CFhVr1vv6P 4kkqZXq3qxu+IKXYn5VaICV00FiSPy6+mCn+OsGz/SSqkOe9n8j6lpMffWqRSGlqoPvJ syT125mP0pM32VL5HPeq/XXdAjFkVl3JlukAHpJkGwRd0fNp/GWTBhAAGy/7mAAceZum C+B4H7kjtuFQmPDYfq7Cf7itUBEaLyep8fQuBgwSnXmh70TtFHlLn5972JLyKjgpFsGw pY6w== 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 i18si23349319ejf.223.2021.01.01.01.06.25; Fri, 01 Jan 2021 01:07:09 -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 S1726830AbhAAJFN convert rfc822-to-8bit (ORCPT + 99 others); Fri, 1 Jan 2021 04:05:13 -0500 Received: from smtp.h3c.com ([60.191.123.50]:18464 "EHLO h3cspam02-ex.h3c.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726525AbhAAJFM (ORCPT ); Fri, 1 Jan 2021 04:05:12 -0500 Received: from DAG2EX01-BASE.srv.huawei-3com.com ([10.8.0.64]) by h3cspam02-ex.h3c.com with ESMTP id 101939aW099159; Fri, 1 Jan 2021 17:03:09 +0800 (GMT-8) (envelope-from gao.yanB@h3c.com) Received: from DAG2EX08-IDC.srv.huawei-3com.com (10.8.0.71) by DAG2EX01-BASE.srv.huawei-3com.com (10.8.0.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Fri, 1 Jan 2021 17:03:12 +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; Fri, 1 Jan 2021 17:03:11 +0800 From: Gaoyan To: Greg KH CC: "jirislaby@kernel.org" , "paulus@samba.org" , "davem@davemloft.net" , "kuba@kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] [v2]net:ppp: remove disc_data_lock in ppp line discipline Thread-Topic: [PATCH] [v2]net:ppp: remove disc_data_lock in ppp line discipline Thread-Index: AdbgF4nu3oTHId93RmKcCrU29a4qZw== Date: Fri, 1 Jan 2021 09:03:11 +0000 Message-ID: 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 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-DNSRBL: X-MAIL: h3cspam02-ex.h3c.com 101939aW099159 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Greg KH: We have a potential race on dereferencing tty->disc_data, so we should use some locks to avoid the competition. In the current version, it defines disc_data_lock to protect the race of ppp_asynctty_receive and ppp_asynctty_close. However, I think when cpu A is running ppp_asynctty_receive, another cpu B will not run ppp_asynctty_close at the same time. The reasons are as follows: Cpu A will hold tty->ldisc_sem before running ppp_asynctty_receive. If cpu B wants to run ppp_asynctty_close, it must wait until cpu A release tty->ldisc_sem after ppp_asynctty_receive. So I think tty->ldisc_sem already can protect the tty->disc_data. About your question: What changed from v1? ==>just change some description. And how did you test this? Why remove this lock, is it causing problems somewhere for it to be here? ==>Somedays ago, There is a problem in n_tty line discipline. Specific description is here: https://lkml.org/lkml/2020/12/9/339 At the beginning I tried to add a lock in the layer of n_tty, until I find the patch https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.9-rc4&id=83d817f41070c48bc3eb7ec18e43000a548fca5c About the patch, Specific description is here: https://lkml.org/lkml/2018/8/29/555 Thanks Gao Yan ----- Original mail ----- On Fri, Jan 01, 2021 at 11:37:18AM +0800, Gao Yan wrote: > In tty layer, it provides tty->ldisc_sem to protect all tty_ldisc_ops > including ppp_sync_ldisc. So I think tty->ldisc_sem can also protect > tty->disc_data, and the disc_data_lock is not necessary. > > 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(-) What changed from v1? And how did you test this? Why remove this lock, is it causing problems somewhere for it to be here? thanks, greg k-h