Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp1817084iob; Thu, 5 May 2022 08:42:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJx+mFvmqTB4AGUPcEFd26MSTaR3dyruIMJXx0wxEP6G/PSnhh/oF2ftI1wb4EYc7uITHLug X-Received: by 2002:a17:907:7e8f:b0:6f5:fc1:e8af with SMTP id qb15-20020a1709077e8f00b006f50fc1e8afmr316370ejc.20.1651765332382; Thu, 05 May 2022 08:42:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651765332; cv=none; d=google.com; s=arc-20160816; b=s2tt6ksZVGhNP8vl+foHdeMz19n5m0cPYERvs2JisX+FqdoB7TbxnR6kNZsGXF4ipi QmHWswO20DxjycxsVNKvSa8gxjoFPfwC/zqBmdMnoTBShJi+kY9Q+HVfQSTKckbPOOkZ KSVODcDh2cM1uqDF487816LHzGThJ21jmCiiHywEo0ZmaRS2oHpmEwtVXVrMtrSEYNzu eXn8FSk+H32xDNxKCFiMxqWipaHmqgYvHRoWdA2lKQV3jLPJjHo7IA0nxx8HXwwn5gCg qDjyhusbmXkxVdj6TRrDh7REharbW/XbBFhxNmLZTAhWkgRXvoaYLgVNAIcrrspigmSu SqgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Yk5oOp7yDV3j9TNnjkwtT5qH11YrtSukrVsnGx7sWtU=; b=J5XUX04FlFsK7hmwkFduXe2uQjNpoecJOvjGlo+XZ4MKeFUDLoDsjhR1O4VFhXrOlI dwk9IWSnI0VvEiQDwQIS1jzPLWqdF9kXl29wRD7/gvm0zqd9JMifYnxk2euS/ivC06/s G9hNh/xq+5h6L/KXICfFNFxELGMIqJMqrc9PPGeDs6a7QPT454gch78cqHCiz8HR+WKQ 5uWd+IwbD2PpCCREaoC+HgbbDh6aynlqTy9928ouRY5ErFMMH6BEinTPiqyXp4WpxWJ8 WweCl7o2rmuq9hTUZdn7PwgA1xTagenTO+Mo7QV0CSZHNHJxT0SK9BgXbMR8H9uFkkyt oz/g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="z5/9vD/f"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gz12-20020a170906f2cc00b006f4f92db142si1630429ejb.635.2022.05.05.08.41.43; Thu, 05 May 2022 08:42:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b="z5/9vD/f"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1358546AbiEDRmj (ORCPT + 99 others); Wed, 4 May 2022 13:42:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1356435AbiEDRJP (ORCPT ); Wed, 4 May 2022 13:09:15 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0358552E72; Wed, 4 May 2022 09:55:07 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id CA786617BD; Wed, 4 May 2022 16:55:07 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 257B3C385AF; Wed, 4 May 2022 16:55:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1651683307; bh=qqOBYkyqIaDFVtLXqkMFTJMInOAayRv70HWCatlXsls=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=z5/9vD/f75HRZ7mFenCZJV6PNgdy5tdZ6DaPQVvaHwL67bB0/kq+uy44/qKslteSR b9NV9BAjyP5OkOcj9KfUJLOSmzCk1oQhZDizgzwXSlnSdXJyibq/lJgF9PDp8fPihX lnjStJNDeYV1TyDUwux2IXOyX4/ppkyiOBZjfGXI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Daniel Starke Subject: [PATCH 5.15 159/177] tty: n_gsm: fix mux cleanup after unregister tty device Date: Wed, 4 May 2022 18:45:52 +0200 Message-Id: <20220504153107.700609775@linuxfoundation.org> X-Mailer: git-send-email 2.36.0 In-Reply-To: <20220504153053.873100034@linuxfoundation.org> References: <20220504153053.873100034@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Daniel Starke commit 284260f278b706364fb4c88a7b56ba5298d5973c upstream. Internally, we manage the alive state of the mux channels and mux itself with the field member 'dead'. This makes it possible to notify the user if the accessed underlying link is already gone. On the other hand, however, removing the virtual ttys before terminating the channels may result in peer messages being received without any internal target. Move the mux cleanup procedure from gsmld_detach_gsm() to gsmld_close() to fix this by keeping the virtual ttys open until the mux has been cleaned up. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Cc: stable@vger.kernel.org Signed-off-by: Daniel Starke Link: https://lore.kernel.org/r/20220414094225.4527-4-daniel.starke@siemens.com Signed-off-by: Greg Kroah-Hartman --- drivers/tty/n_gsm.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/drivers/tty/n_gsm.c +++ b/drivers/tty/n_gsm.c @@ -2418,7 +2418,6 @@ static void gsmld_detach_gsm(struct tty_ WARN_ON(tty != gsm->tty); for (i = 1; i < NUM_DLCI; i++) tty_unregister_device(gsm_tty_driver, base + i); - gsm_cleanup_mux(gsm, false); tty_kref_put(gsm->tty); gsm->tty = NULL; } @@ -2483,6 +2482,12 @@ static void gsmld_close(struct tty_struc { struct gsm_mux *gsm = tty->disc_data; + /* The ldisc locks and closes the port before calling our close. This + * means we have no way to do a proper disconnect. We will not bother + * to do one. + */ + gsm_cleanup_mux(gsm, false); + gsmld_detach_gsm(tty, gsm); gsmld_flush_buffer(tty);