Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2333640ybz; Thu, 23 Apr 2020 16:12:50 -0700 (PDT) X-Google-Smtp-Source: APiQypLbzfhxHKuq7WAIBJ1RUtYZrC4ReW7QywqN1qz50TxakBDKip4SF0LSnaKftNuWOT97GqSI X-Received: by 2002:a05:6402:b2a:: with SMTP id bo10mr5061977edb.366.1587683570041; Thu, 23 Apr 2020 16:12:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683570; cv=none; d=google.com; s=arc-20160816; b=xLRiSs/qYbDM0v1uJ1zp06VwUHQaxW1n0Jh1vv1acBm7cDlf/PhsbKdOXrIV53DvVJ YzfLxqJ9eyQMx+xsna8yhOxCaNRQJeYGtwWPa05vJWZLqe7QQfp/0CMKQHkVlAao/Dtt 0KCDCNZsPd+KcOZM+KsWT1Nr7zr6snq70bdUyU8m3xhyDYvBHpF6l1Z+tmiUdVGqNpc7 C+oCkccgzpV2sJMrv+madr335wZiHOQuH5n6FEU62D3BTteta0YIbEzHSKmFJIP1DxFK aekJ4vuMt10W2FzEPoUpC5CWBOKH6F7BnnORUcRsQYIeh1M5h13fPx9S+Xe+v4a4pTug Rb/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=oLGepxTXLvw5tlEbsYqi1UjBRcOrtx4Wf+5rYU2cIZY=; b=DFWjGsJylVyfTUqrZv9iejft6L1ioAeh1272o82+N3EPsiiyY9dGr2KEy5m0neGQ+y Duy9lg7/gs/T0g6i2M8EIzgrZ5ml4gn31IWlQTlNJc5c0Uyxwd+qg6LnJ9RwVS7DC4HD pi1JByc9pE+Nsb7km0Qdoe6aA8/hNMapdyncdm3LGlMVK7d/gIHKaixm8Rs/grXX9cIk mwMRC9fWtPyCuwzZqF5EOnT5UxIWpMvH2YR3voCmHtRbO3Yl+ZvQWarj2HUvT0PvrH3n ozBsvvqqBP0nSM64Dx9j8aIAGHRA8dRlc0L4zIdWeDMUyyPjfyaGaa788p0Ja/ZLfkZb g9ww== 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 k5si1999547ejj.441.2020.04.23.16.12.26; Thu, 23 Apr 2020 16:12:50 -0700 (PDT) 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 S1728833AbgDWXKB (ORCPT + 99 others); Thu, 23 Apr 2020 19:10:01 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:50682 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728619AbgDWXGz (ORCPT ); Thu, 23 Apr 2020 19:06:55 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvi-0004vG-0f; Fri, 24 Apr 2020 00:06:50 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvd-00E71u-GP; Fri, 24 Apr 2020 00:06:45 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Greg Kroah-Hartman" , "Jiri Slaby" Date: Fri, 24 Apr 2020 00:07:27 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 220/245] vt: selection, handle pending signals in paste_selection In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Jiri Slaby commit 687bff0cd08f790d540cfb7b2349f0d876cdddec upstream. When pasting a selection to a vt, the task is set as INTERRUPTIBLE while waiting for a tty to unthrottle. But signals are not handled at all. Normally, this is not a problem as tty_ldisc_receive_buf receives all the goods and a user has no reason to interrupt the task. There are two scenarios where this matters: 1) when the tty is throttled and a signal is sent to the process, it spins on a CPU until the tty is unthrottled. schedule() does not really echedule, but returns immediately, of course. 2) when the sel_buffer becomes invalid, KASAN prevents any reads from it and the loop simply does not proceed and spins forever (causing the tty to throttle, but the code never sleeps, the same as above). This sometimes happens as there is a race in the sel_buffer handling code. So add signal handling to this ioctl (TIOCL_PASTESEL) and return -EINTR in case a signal is pending. Signed-off-by: Jiri Slaby Link: https://lore.kernel.org/r/20200210081131.23572-1-jslaby@suse.cz Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: - No need to include - Adjust context] Signed-off-by: Ben Hutchings --- --- a/drivers/tty/vt/selection.c +++ b/drivers/tty/vt/selection.c @@ -341,6 +341,7 @@ int paste_selection(struct tty_struct *t unsigned int count; struct tty_ldisc *ld; DECLARE_WAITQUEUE(wait, current); + int ret = 0; console_lock(); poke_blanked_console(); @@ -352,6 +353,10 @@ int paste_selection(struct tty_struct *t add_wait_queue(&vc->paste_wait, &wait); while (sel_buffer && sel_buffer_lth > pasted) { set_current_state(TASK_INTERRUPTIBLE); + if (signal_pending(current)) { + ret = -EINTR; + break; + } if (test_bit(TTY_THROTTLED, &tty->flags)) { schedule(); continue; @@ -367,5 +372,5 @@ int paste_selection(struct tty_struct *t tty_buffer_unlock_exclusive(&vc->port); tty_ldisc_deref(ld); - return 0; + return ret; }