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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06130C43217 for ; Tue, 22 Nov 2022 09:05:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 855506B0073; Tue, 22 Nov 2022 04:05:36 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DE3180008; Tue, 22 Nov 2022 04:05:36 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 659BA80007; Tue, 22 Nov 2022 04:05:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 537C06B0073 for ; Tue, 22 Nov 2022 04:05:36 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 28E0A1A0E1C for ; Tue, 22 Nov 2022 09:05:36 +0000 (UTC) X-FDA: 80160495072.26.845AD69 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf25.hostedemail.com (Postfix) with ESMTP id B9178A0010 for ; Tue, 22 Nov 2022 09:05:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1669107935; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=h2fTDZU7Y2Vrqet95Gjzc0cvOcSZU6gDzpfc8yLs0sg=; b=bhfFTDWqbXIsDsfnTDxHD5hZA1telqXgFv+y6bWuTnyVYzrRqtqqlWEuA40Cfy79CCOI61 y2ep0Mo2AsMcr1Iykc31MGSfs0MYXNJaNp79BABxqrdUWtM7o/Fr+nOR1NElwaciz9Qrnx FgRWy1S+o8JxEuL448kUG5TXHwdQa8Q= Received: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-220-OTVl67qzOKWEiS6jxt0XGg-1; Tue, 22 Nov 2022 04:05:31 -0500 X-MC-Unique: OTVl67qzOKWEiS6jxt0XGg-1 Received: by mail-wm1-f69.google.com with SMTP id p14-20020a05600c204e00b003cf4cce4da5so3845802wmg.0 for ; Tue, 22 Nov 2022 01:05:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=h2fTDZU7Y2Vrqet95Gjzc0cvOcSZU6gDzpfc8yLs0sg=; b=0JMk2Cz/8004/KQyi2HvPXJL17fV33rTnOG+yFqjPRRtarKq+tJ5UQIu/ILY+a5RNe EOA8XtN2fbmHIHY9/yuyDp0eewesZ4SVe2MhuPkJR1X376OGiLMRN8JjlQCIRnUkP/8q LkovLALdQFDrosDoL4wRaKsVRpBfK11Aqk54x9oLFjGfCxeTjbBV+6yy2RHh8aFF3mgk HTF2i4DCauX2o7Nh6AU+XZJREgq20/E8klmIuZfWA985FYz3r4PCtmKjqLmJlEc+EtVu Bhbp1RKOhOzMXFoPDYHyzekeWCtcCDfL0dwCBo2tiOuztDOzoKTOJVN7s9dTf3khqL48 8Hgw== X-Gm-Message-State: ANoB5pmESImfauSo1Oodv2QCJ7NB73HcPMCdm6//T9yXB44hwqm5ILdq C40aG8KOPglJgx2LErcEbqJyHwj8J8GFsSsJHMBh7YfIWEnk2I95madEld2fTNyeZoCOdPH+bT8 TPTCF7mE2myc= X-Received: by 2002:a1c:f617:0:b0:3cf:e0ef:1f69 with SMTP id w23-20020a1cf617000000b003cfe0ef1f69mr1705947wmc.163.1669107930579; Tue, 22 Nov 2022 01:05:30 -0800 (PST) X-Google-Smtp-Source: AA0mqf4Y7DTNGbgnoPxPhqhwn0MjeYOzXwVXxc/cY3rCYpWGnVrKPTxJSydpEx0fntgGVLmBqTEGAw== X-Received: by 2002:a1c:f617:0:b0:3cf:e0ef:1f69 with SMTP id w23-20020a1cf617000000b003cfe0ef1f69mr1705909wmc.163.1669107930184; Tue, 22 Nov 2022 01:05:30 -0800 (PST) Received: from [192.168.3.108] (p5b0c65c4.dip0.t-ipconnect.de. [91.12.101.196]) by smtp.gmail.com with ESMTPSA id v17-20020a5d5911000000b00241da0e018dsm4073477wrd.29.2022.11.22.01.05.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 22 Nov 2022 01:05:29 -0800 (PST) Message-ID: <4b926dc7-b8ec-e363-b9d8-35c0f2c897f6@redhat.com> Date: Tue, 22 Nov 2022 10:05:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 To: Andrew Morton Cc: Mike Kravetz , Jason Gunthorpe , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Peter Xu , John Hubbard , syzbot+f0b97304ef90f0d0b1dc@syzkaller.appspotmail.com References: <20221031152524.173644-1-david@redhat.com> <20221121133320.a4e1c70af6ca72f29795fd5f@linux-foundation.org> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH v1] mm/gup: disallow FOLL_FORCE|FOLL_WRITE on hugetlb mappings In-Reply-To: <20221121133320.a4e1c70af6ca72f29795fd5f@linux-foundation.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669107935; a=rsa-sha256; cv=none; b=OotA37tYc8xKhh2cpj1NfZsilMVt3o9NYum1e1qtNqFK5XdWI8GHwOJJCZf3pbG0sR5AfV dToufIFgmSH5i50DMH3LVe+66eGkoFQ717p6usimxgNicsB8xCRf2afAhRVmbfnbOM+gjs oPLYUsqhMGBBOGP7lDaFCdjRMPf9ay0= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bhfFTDWq; spf=pass (imf25.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669107935; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=h2fTDZU7Y2Vrqet95Gjzc0cvOcSZU6gDzpfc8yLs0sg=; b=PN5eL6/0D1iB/mjFo4UHgZ2I05fyYpa/t8Ifh7KTjEHP+MDSBseQ1nI5o9xrhGs8jJB4PA N2vDrYMujkXsskxe3WYzJFaZAXLZA7rPh/BUVo8t84Ti10SjuI8T+kkqd3i6jS3IyfMh5Q i4OciRaRrKUHDIHMEVVGv320n2nq5iE= X-Stat-Signature: tr8cnme15h3k3n3857bc8ygxmxqd8mud X-Rspamd-Queue-Id: B9178A0010 X-Rspam-User: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=bhfFTDWq; spf=pass (imf25.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspamd-Server: rspam02 X-HE-Tag: 1669107935-788445 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 21.11.22 22:33, Andrew Morton wrote: > On Mon, 21 Nov 2022 09:05:43 +0100 David Hildenbrand wrote: > >>>> MikeK do you have test cases? >>> >>> Sorry, I do not have any test cases. >>> >>> I can ask one of our product groups about their usage. But, that would >>> certainly not be a comprehensive view. >> >> With >> >> https://lkml.kernel.org/r/20221116102659.70287-1-david@redhat.com >> >> on it's way, the RDMA concern should be gone, hopefully. >> >> @Andrew, can you queue this one? Thanks. > > This is all a little tricky. > > It's not good that 6.0 and earlier permit unprivileged userspace to > trigger a WARN. But we cannot backport this fix into earlier kernels > because it requires the series "mm/gup: remove FOLL_FORCE usage from > drivers (reliable R/O long-term pinning)". > > Is it possible to come up with a fix for 6.1 and earlier which won't > break RDMA? Let's recap: (1) Nobody so far reported a RDMA regression, it was all pure speculation. The only report we saw was via ptrace when fuzzing syscalls. (2) To trigger it, one would need a hugetlb MAP_PRIVATE mappings without PROT_WRITE. For example: mmap(0, SIZE, PROT_READ, MAP_PRIVATE|MAP_ANON|MAP_HUGETLB|MAP_HUGE_2MB, -1, 0) or mmap(0, SIZE, PROT_READ, MAP_PRIVATE, hugetlbfd, 0) While that's certainly valid, it's not the common use case with hugetlb pages. (3) Before 1d8d14641fd9 (< v6.0), it "worked by accident" but was wrong: pages would get mapped writable into page tables, even though we did not have VM_WRITE. FOLL_FORCE support is essentially absent but not fenced properly. (4) With 1d8d14641fd9 (v6.0 + v6.1-rc), it results in a warning instead. (5) This patch silences the warning. Ways forward are: (1) Implement FOLL_FORCE for hugetlb and backport that. Fixes the warning in 6.0 and wrong behavior before that. The functionality, however, might not be required in 6.2 at all anymore: the last remaining use case would be ptrace (which, again, we don't have actual users reporting breakages). (2) Use this patch and backport it into 6.0/6.1 to fix the warning. RDMA will be handled properly in 6.2 via reliable long-term pinnings. (3) Use this patch and backport it into 6.0/6.1 to fix the warning. Further, backport the reliable long-term pinning changes into 6.0/6.1 if there are user reports. (4) On user report regarding RDMA in 6.0 and 6.1, revert the sanity check that triggers the warning and restore previous (wrong) behavior. To summarize, the benefit of (1) would be to have ptrace on hugetlb COW mappings working. As stated, I'd like to minimize FOLL_FORCE implementations if there are no legacy users because FOLL_FORCE has a proven record of security issues. Further, backports to < 6.0 might not be straight forward. I'd suggest (2), but I'm happy to hear other opinions. -- Thanks, David / dhildenb