Received: by 10.192.165.148 with SMTP id m20csp787284imm; Wed, 25 Apr 2018 07:41:21 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/+LEc2rWVHQrWG6FgnNPioCje3y5+ffNWl4S+ZA/HZn0M9SyeB+zvrRmsWJdAnzoGynXro X-Received: by 2002:a17:902:8d98:: with SMTP id v24-v6mr29127040plo.146.1524667281288; Wed, 25 Apr 2018 07:41:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524667281; cv=none; d=google.com; s=arc-20160816; b=z3oWf1lgniVpGbuJhKdTkXmqO2sfLZ7rlHydTYQV87YtX5ZKNU/MHnjWugIdJ3onxu FPC3kA5zU8+ELDS3v8FU2MugObj1LqC0EhLcF9oD2w4uoHj16bdnroVzSJ1Q0ovN3xYd iVIvUknd3nsu+LR4Z0webTs+/2K5swk+Nh6voDNzx9izpub6g2Q8l6aBV1OytvjY7x8G mYYIUELCajQ22EuaKdOESxEfzK+u0ZbnzvIPsY1X/MDszNJSkOY19haGYP4636R4meh8 UOMDFcr3mIp8JxigakMN01kTshqPo2EZPrKnspKIivjH23wX+DqX1X2IsiyQ02FQft/M 7IxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=VkYFyjaKEO6ycwZ1P9TKjfsZKSVjq+ymwcQ5AumqZgc=; b=EdriWrFrzatpk5hyDgxANIVW1q2J8qYTsj0HjtI1AOmmofRGXPA27zmWPJDb07qlBR 9myLfmYkvedwDss4fVBdpbneSfZFfCG1wOILL7kB5XRmQtou4AAZTpP+YZKv0qCQ5qqs bBzHyejqcfcWNSdRvcMNftRGfZOqMs29WTFSM98M9FiQklzZZKvOOlxuF/OZVxNfKgEE 9Bz0GnOjZrkl1V5xPVvdKpYTdAtXBUhS3hHUSVrnhsiOUE3oof9jIRUjZF+Fud9LpQAb nLhOCvQ3NZp9PwCpCgYXoo0w5m+cAWB4ZTOhXYx9khBdH69PQaxn9Bd2vhd7r6rALqxm ocwg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u10si13291118pgr.221.2018.04.25.07.41.07; Wed, 25 Apr 2018 07:41:21 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754677AbeDYOkB (ORCPT + 99 others); Wed, 25 Apr 2018 10:40:01 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:60350 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753327AbeDYOkA (ORCPT ); Wed, 25 Apr 2018 10:40:00 -0400 Received: from alans-desktop (82-70-14-226.dsl.in-addr.zen.co.uk [82.70.14.226]) by fuzix.org (8.15.2/8.15.2) with ESMTP id w3PEdnXh027382; Wed, 25 Apr 2018 15:39:49 +0100 Date: Wed, 25 Apr 2018 15:39:48 +0100 From: Alan Cox To: DaeRyong Jeong Cc: gregkh@linuxfoundation.org, jslaby@suse.com, byoungyoung@purdue.edu, kt0755@gmail.com, bammanag@purdue.edu, linux-kernel@vger.kernel.org Subject: Re: [PATCH] tty: Fix data race in tty_insert_flip_string_fixed_flag Message-ID: <20180425153948.7be2bc57@alans-desktop> In-Reply-To: <20180425132047.GA20337@dragonet.kaist.ac.kr> References: <20180425132047.GA20337@dragonet.kaist.ac.kr> Organization: Intel Corporation X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Apr 2018 22:20:50 +0900 DaeRyong Jeong wrote: > tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated > by th->used and updates tb->used. > But tty_insert_flip_string_fixed_flag() can be executed concurrently and > tb->used can be updated improperly. The tty input layer does not work if it can be executed concurrently. If that is happening in the pty code then the pty code is buggy and that needs serializing on the inbound path. > -static void tty_write_unlock(struct tty_struct *tty) > +void tty_write_unlock(struct tty_struct *tty, int wakeup) > { > mutex_unlock(&tty->atomic_write_lock); > - wake_up_interruptible_poll(&tty->write_wait, EPOLLOUT); > + if (wakeup) { > + wake_up_interruptible_poll(&tty->write_wait, EPOLLOUT); > + } And this may cause deadlocks. You don't actually need any of the wakeup changes in your code > diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c > index d9b561d89432..a54ab91aec90 100644 > --- a/drivers/tty/tty_ioctl.c > +++ b/drivers/tty/tty_ioctl.c > @@ -911,12 +911,17 @@ int n_tty_ioctl_helper(struct tty_struct *tty, struct file *file, > spin_unlock_irq(&tty->flow_lock); > break; > case TCOON: > + if (tty_write_lock(tty, 0) < 0) > + return -ERESTARTSYS; > + > spin_lock_irq(&tty->flow_lock); > if (tty->flow_stopped) { > tty->flow_stopped = 0; > __start_tty(tty); > } > spin_unlock_irq(&tty->flow_lock); > + > + tty_write_unlock(tty, 0); If you just used these unmodified it would be simpler and as good, however it won't actually fix anything. The pty layer is broken not this code. The tty layer rule for all the input buffer handling is that you may not call *any* of it from multiple threads at once. This works fine for normal serial because the IRQ layer or the polling logic has that property. The bug looks real, your diagnosis looks right, your fix sort of works but isn't sufficient. So NAK. Alan