Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2077787ybi; Sun, 9 Jun 2019 03:13:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqxOpFalRVnZ2gywVh8dLso+gn0eYPzrVX7S/r6s4WxMIc1CcXxCSGFBcFLD+9SiP4Sv76R+ X-Received: by 2002:a17:90a:aa81:: with SMTP id l1mr14806340pjq.55.1560075204659; Sun, 09 Jun 2019 03:13:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560075204; cv=none; d=google.com; s=arc-20160816; b=KjceSIAa9YKDhUQglOLaa0h5F0KKgSutxJlCsb4J765NlYJdIE3hZ+E9AMfRFv4bmW HI/7j29Jx7dz/P1AbcDlNDP4XlVvReH5k068f1ocnVW2ihn1/YheONnliIQ4YeVwwDqy 1m4dAg/nrkP2AAB0FJFyt/X/rwBegRcJZ3kGa/ulcE+eyQBbYGxI5653yjOVJdc2044R s5Oz408qsPLmIg80eU71eUbqrOlYGq4XVVwxZBtRlIcScvWrij1pDpSjUEFP7ytbXOe5 6NwJOHC72TL8nps0LMO8upt+nsT7Lsgdi5pKTlsXqeKV+mSwfOttLMFQj6a/NawkRHsX LgWw== 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 :user-agent:references:in-reply-to:message-id:date:cc:to:from :subject:dkim-signature; bh=JjGSbXYSmI2Txw4mQvoTR75+oGXHH64lCXqV4geoUls=; b=RZI0LUhW5UTMAL+1fYWAPM6SyUtQ6USjQPORmGWXFaIxnYiIhISvRsBrzGnZrUh+OE re0JQcfeojK1QB2241nt+Gk+3rmJGC40gK83c43LR0+PcE4y6MXzPmO6vH9cmXw231Ci iTIjPf+GIFNgweIGhatM+ylKo0x7kpqlCsGuzf2anib6iP4+y6RaHSAntG3DixA4BHpF xr6dFpq3M48R+xcrr+PUf5rcwLpUts6f5ha+ZzBufbL08/KPlAWu5OQXU/77MKxoZbQG uXaEnPMllncgQZC4yI8LpWNy3m56QoTf5rjEAxbKc0sO/OoirZXT2PR23Wr8QDv2xTMj ujHg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@yandex-team.ru header.s=default header.b=z05nsIep; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b22si6627755plz.417.2019.06.09.03.13.08; Sun, 09 Jun 2019 03:13:24 -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; dkim=pass header.i=@yandex-team.ru header.s=default header.b=z05nsIep; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yandex-team.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728275AbfFIKJK (ORCPT + 99 others); Sun, 9 Jun 2019 06:09:10 -0400 Received: from forwardcorp1o.mail.yandex.net ([95.108.205.193]:55298 "EHLO forwardcorp1o.mail.yandex.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728231AbfFIKJF (ORCPT ); Sun, 9 Jun 2019 06:09:05 -0400 Received: from mxbackcorp2j.mail.yandex.net (mxbackcorp2j.mail.yandex.net [IPv6:2a02:6b8:0:1619::119]) by forwardcorp1o.mail.yandex.net (Yandex) with ESMTP id B8BB62E128E; Sun, 9 Jun 2019 13:09:02 +0300 (MSK) Received: from smtpcorp1p.mail.yandex.net (smtpcorp1p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:10]) by mxbackcorp2j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id GPVqI98PV5-92dCP51C; Sun, 09 Jun 2019 13:09:02 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex-team.ru; s=default; t=1560074942; bh=JjGSbXYSmI2Txw4mQvoTR75+oGXHH64lCXqV4geoUls=; h=In-Reply-To:Message-ID:References:Date:To:From:Subject:Cc; b=z05nsIep3y7fvuABy75loevMGYRGUtTHeQP1HW8df8+IXOW2u4oPs4rqs77tk3V1T ySkTzZ5JZMrZYc4IRni1naQVfoWdJ/CQ7/qbULv2tO3ILPiMJ0Mts/9/h9VdWHIUQC yK30fHdHJgvsU48poLX+VtrcTBd9hqYMjvZRVDaM= Authentication-Results: mxbackcorp2j.mail.yandex.net; dkim=pass header.i=@yandex-team.ru Received: from dynamic-red.dhcp.yndx.net (dynamic-red.dhcp.yndx.net [2a02:6b8:0:40c:3d25:9e27:4f75:a150]) by smtpcorp1p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id RlV9qeaXk1-92gun05E; Sun, 09 Jun 2019 13:09:02 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) Subject: [PATCH v2 6/6] mm: use down_read_killable for locking mmap_sem in access_remote_vm From: Konstantin Khlebnikov To: linux-mm@kvack.org, Andrew Morton , linux-kernel@vger.kernel.org Cc: Oleg Nesterov , Matthew Wilcox , Michal Hocko , Cyrill Gorcunov , Kirill Tkhai , Michal =?utf-8?q?Koutn=C3=BD?= , Al Viro , Roman Gushchin Date: Sun, 09 Jun 2019 13:09:02 +0300 Message-ID: <156007494202.3335.16782303099589302087.stgit@buzz> In-Reply-To: <156007465229.3335.10259979070641486905.stgit@buzz> References: <156007465229.3335.10259979070641486905.stgit@buzz> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This function is used by ptrace and proc files like /proc/pid/cmdline and /proc/pid/environ. Access_remote_vm never returns error codes, all errors are ignored and only size of successfully read data is returned. So, if current task was killed we'll simply return 0 (bytes read). Mmap_sem could be locked for a long time or forever if something wrong. Killable lock allows to cleanup stuck tasks and simplifies investigation. Signed-off-by: Konstantin Khlebnikov Reviewed-by: Michal Koutný Acked-by: Oleg Nesterov Acked-by: Michal Hocko --- mm/memory.c | 4 +++- mm/nommu.c | 3 ++- 2 files changed, 5 insertions(+), 2 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index ddf20bd0c317..9a4401d21e94 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -4349,7 +4349,9 @@ int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm, void *old_buf = buf; int write = gup_flags & FOLL_WRITE; - down_read(&mm->mmap_sem); + if (down_read_killable(&mm->mmap_sem)) + return 0; + /* ignore errors, just check how much was successfully transferred */ while (len) { int bytes, ret, offset; diff --git a/mm/nommu.c b/mm/nommu.c index d8c02fbe03b5..b2823519f8cd 100644 --- a/mm/nommu.c +++ b/mm/nommu.c @@ -1792,7 +1792,8 @@ int __access_remote_vm(struct task_struct *tsk, struct mm_struct *mm, struct vm_area_struct *vma; int write = gup_flags & FOLL_WRITE; - down_read(&mm->mmap_sem); + if (down_read_killable(&mm->mmap_sem)) + return 0; /* the access must start within one of the target process's mappings */ vma = find_vma(mm, addr);