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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 7ED20C4363D for ; Fri, 2 Oct 2020 12:01:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4140E206A4 for ; Fri, 2 Oct 2020 12:01:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601640096; bh=zbiiuyF5kjvD4Hk79n0s5rZqUD3LAi6erjiDnLetCJk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=SVKLZESim1VEzpiOIomuzV8uB9nYaOcLy4+vaoZuTTY0V8DABuMXkoVEnpSoUtdfv LpIxxQKKnqyGxGAalj8tXRAx3WihzfKYdKCLI+UGOph34YsJX7roP6vV0I536PxMcK 47TaAi8wjQ7ZkrhxrmyMLF1qet5DQVGtY8hLfYSs= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387822AbgJBMBf (ORCPT ); Fri, 2 Oct 2020 08:01:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:53494 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726090AbgJBMBe (ORCPT ); Fri, 2 Oct 2020 08:01:34 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (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 DB624206A2; Fri, 2 Oct 2020 12:01:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1601640094; bh=zbiiuyF5kjvD4Hk79n0s5rZqUD3LAi6erjiDnLetCJk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aJPgagblHWUFpqbxqUSneM6YdWH/dllJTLnhIWqtaZHi2cVY3vJfn/mBFe3245uIg zjr9vP9lZbkdo27whBOhPtnRwyAX8hteZwNtTqqvcZ06RIWx/JyuMLKT7n8Pc+ml8v +fHZtIIhTTAHAnYwE04mAFoMcR7edrtUvmq0UWiM= Date: Fri, 2 Oct 2020 14:01:33 +0200 From: Greg Kroah-Hartman To: minyard@acm.org Cc: Jiri Slaby , LKML , Corey Minyard Subject: Re: [PATCH] drivers:tty:pty: Fix a race causing data loss on close Message-ID: <20201002120133.GB3339665@kroah.com> References: <20201002021630.4892-1-minyard@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201002021630.4892-1-minyard@acm.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 01, 2020 at 09:16:30PM -0500, minyard@acm.org wrote: > From: Corey Minyard > > If you write to a pty master an immediately close the pty master, the > receiver might get a chunk of data dropped, but then receive some later > data. That's obviously something rather unexpected for a user. It > certainly confused my test program. > > It turns out that tty_vhangup() gets called from pty_close(), and that > causes the data on the slave side to be flushed, but due to races more > data can be copied into the slave side's buffer after that. Consider > the following sequence: > > thread1 thread2 thread3 > write data into buffer, > n_tty buffer is filled > pty_close() > tty_vhangup() > tty_ldisc_hangup() > n_tty_flush_buffer() > reset_buffer_flags() > n_tty_read() > up_read(&tty->termios_rwsem); > down_read(&tty->termios_rwsem); > clear n_tty buffer contents > up_read(&tty->termios_rwsem); > tty_buffer_flush_work() > schedules work calling > flush_to_ldisc() > flush_to_ldisc() > receive_buf() > tty_port_default_receive_buf() > tty_ldisc_receive_buf() > tty_ldisc_receive_buf() > n_tty_receive_buf2() > n_tty_receive_buf_common() > down_read(&tty->termios_rwsem); > __receive_buf() > copies data into n_tty buffer > up_read(&tty->termios_rwsem); > down_read(&tty->termios_rwsem); > copy buffer data to user Your text got line-wrapped here for this explaination and it doesn't make much sense :( Can you resend this? > This change checks to see if the tty is being hung up before copying > anything in n_tty_receive_buf_common(). It has to be done after the > tty->termios_rwsem semaphore is claimed, for reasons that should be > apparent from the sequence above. That kind of makes sense, but it's tricky, if you resend with the above fixed it might be more obvious... thanks, greg k-h