Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp64293imu; Thu, 10 Jan 2019 18:09:47 -0800 (PST) X-Google-Smtp-Source: ALg8bN4nO7yqMVgxt1XHYvtjk03xg06v3xk14NLUHU5ZlfLnG9VMhkNmOyCw0nzBUE9UFiGZpmER X-Received: by 2002:a62:1e87:: with SMTP id e129mr12503695pfe.221.1547172587152; Thu, 10 Jan 2019 18:09:47 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547172587; cv=none; d=google.com; s=arc-20160816; b=bWvI3M9Dii3vgGeeCtW2XU7hnjjz9hQBjl7GttONUT0zWh00H+fyi91mXNRPWREfWR tuIYCdmOHVuHCNWBx7l0zcBjp6UYYN3+PiyA6crGAQJ106B8pS1bobMkv2/jX4V7uQpQ boUPn8rHqZkkLdwiMU03oU8n+xIIAQeeo7OFdHdchfaey/n0LT0tf69nZod5qWoYFW9c Pb3VXOvsLLeKWSd0WMa6Cjezh5VHtLlJ4C6UJ/M8A/pJiLcq+SU4JUHHtFH9/BIfv3RE gZ1i17ZCduVkdmHCXThBRU4QJuaUIXtDqqL9BhQYC6jH8oY6ukZ7LsoU6ZdGnkdB+dp6 mxag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=TlBEbWJPRxW5ErqdsgMFn18xJNa8zguibIlrpYIe8GE=; b=Xy7p76cMi4KkRgYwI+Z5cwcBhdxMQpavQ7Lq/x+8fofinXjH6WdWvE/MpEmyPzVL9X 73HxzlcL8ZW1G6SdNfBJAZy/QYmY1+QKTuS8dwNiUE1rHki4194xAZELAfRFqmamPQVt GEA7K3Glz0qLbmYopSiwpM8Xf45TduymhAbKn9u0k/HOXLQfe7+5QaCCWTH78VFdpJAF /kFJNiZpAoBf3pHik0HzngE/gIEpzcPr91NZq/LhnUBTpxpbUMLzh/f8e/iwcwBqt1Dg oM7f+c9ZtMuz/fe6+NLGegEsvgp+HrjQgQamHzyIijrlT1LfDRUEsy9xhKD0VxqFeiW8 YbBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=F2LZhLAo; 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 a19si5801539pgn.102.2019.01.10.18.09.31; Thu, 10 Jan 2019 18:09:47 -0800 (PST) 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=@linux-foundation.org header.s=google header.b=F2LZhLAo; 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 S1728478AbfAJV7c (ORCPT + 99 others); Thu, 10 Jan 2019 16:59:32 -0500 Received: from mail-lj1-f193.google.com ([209.85.208.193]:45253 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727653AbfAJV7c (ORCPT ); Thu, 10 Jan 2019 16:59:32 -0500 Received: by mail-lj1-f193.google.com with SMTP id s5-v6so11085880ljd.12 for ; Thu, 10 Jan 2019 13:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TlBEbWJPRxW5ErqdsgMFn18xJNa8zguibIlrpYIe8GE=; b=F2LZhLAoZnai3Q/v7fqXciTy8NtdW1LrmXu1KcpK9bQSVTukW+I9Mw0wK2XcWeA9e+ RVI6eeeDM1+p8dJs4yLa7J8+GdgociTJLV6U/KCmP4VUU9Vq83aqthiREo2n7NIy8u6k T8BgPlRn/3ksKc7fBjzS7SBQFWfgmrHc8MZTM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TlBEbWJPRxW5ErqdsgMFn18xJNa8zguibIlrpYIe8GE=; b=pgC0TKVIqJuT1JvSI1RXUN7pq1Tc3vJMqYO2VMwIVYf8Nr+WnF6Nyxbec1QVaE1l8n FyeZwJdhQX3hd+fKX0MaOZMz1ItF0Iqrjb4Adv0/ef4HTMJzdT4GCMWJ+r79/LmCZjD/ r0kgEsEqCILwlRtUT9IFe3nBJQXdKo7aKzVX9V4iizXq9SP6wiS1a7PHbFNrSMIiJnEr G3ks6ECOwsDmhgAZiiRfNykg+N6kE2DbS1B4jtV1Oe4BwBLAIp08olDlLvqjlAoU1s0b e/gP8KMGf0Qt8G4fsc8qtAvBCDT9PNj3WjOBDWJe7OgjJvPEHLnu1UD48Aqk+n0UvKDJ fuhw== X-Gm-Message-State: AJcUukfACR6fEyL5Mrp+yOodJk2tXZO5ll/5FmpODmlcXSbpUTr8Eyw6 rzndoQlF2dSdWcw9StINPYVFxG1StoU= X-Received: by 2002:a2e:5356:: with SMTP id t22-v6mr6686535ljd.26.1547157569680; Thu, 10 Jan 2019 13:59:29 -0800 (PST) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com. [209.85.208.173]) by smtp.gmail.com with ESMTPSA id g3-v6sm15701863lje.50.2019.01.10.13.59.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Jan 2019 13:59:28 -0800 (PST) Received: by mail-lj1-f173.google.com with SMTP id k19-v6so11093384lji.11 for ; Thu, 10 Jan 2019 13:59:28 -0800 (PST) X-Received: by 2002:a2e:310a:: with SMTP id x10-v6mr7603918ljx.6.1547157568146; Thu, 10 Jan 2019 13:59:28 -0800 (PST) MIME-Version: 1.0 References: <20190108044336.GB27534@dastard> <20190109022430.GE27534@dastard> <20190109043906.GF27534@dastard> <20190110004424.GH27534@dastard> <20190110144711.GV6310@bombadil.infradead.org> <20190110214427.GK27534@dastard> In-Reply-To: <20190110214427.GK27534@dastard> From: Linus Torvalds Date: Thu, 10 Jan 2019 13:59:12 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged To: Dave Chinner Cc: Matthew Wilcox , Andy Lutomirski , Jiri Kosina , Jann Horn , Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , Linux-MM , kernel list , Linux API Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 10, 2019 at 1:44 PM Dave Chinner wrote: > > GUP does page fault on user buffer which is a mmapped region of same > file. page fault sets up for buffered IO, tries to take rwsem for > write, deadlocks. > > Most of the schemes we come up with fall down at this point - you > can't hold a lock over gup that is also used in the buffered IO > path. That's why XFS (and now ext4) have the IOLOCK and MMAPLOCK > for truncation serialisation - we can't lock out both read()/write() > and mmap IO paths with the same lock... Side note: a somewhat similar version of is true even in the absence of GUP and dio, for the case of doing a mmap of a file, and then reading or writing from the mapped region into the file itself. There are "interesting" locking scenarios wrt just holding the page locked, and trying to then fill that page with information with just a regular "copy_from_user()". Page fault -> try to read the file -> oops, the page we're trying to read from is locked because we're trying to write to it. So we have that odd dance in generic_perform_write() which does - touch the first user byte without holding any lock - do write_begin() (which gets the page lock) - copy from user space using the "atomic" copy (which just gives up on fault) - if nothing got copied, go back and try again with a smaller copy that can't cross a page. We might have raced with pageout. It might be possible to do something similar for direct IO, although simpler: just do the GUP entirely atomically (and in the fault case just fall back to non-direct IO). Linus