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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F11CFC388F7 for ; Fri, 13 Nov 2020 13:39:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4564822245 for ; Fri, 13 Nov 2020 13:39:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4564822245 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=cornelisnetworks.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AEF3C6B0073; Fri, 13 Nov 2020 08:39:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A9E7F6B0074; Fri, 13 Nov 2020 08:39:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B4D46B007E; Fri, 13 Nov 2020 08:39:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0205.hostedemail.com [216.40.44.205]) by kanga.kvack.org (Postfix) with ESMTP id 69EE96B0073 for ; Fri, 13 Nov 2020 08:39:34 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 0C8158249980 for ; Fri, 13 Nov 2020 13:39:34 +0000 (UTC) X-FDA: 77479502268.08.bed68_180fdce2730f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id E00CB1819E766 for ; Fri, 13 Nov 2020 13:39:33 +0000 (UTC) X-HE-Tag: bed68_180fdce2730f X-Filterd-Recvd-Size: 3110 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Nov 2020 13:39:33 +0000 (UTC) IronPort-SDR: iZCzxC3npRiL+VN+aEgP748WDI+xatBZzA8EKnS/OGRy/Jp/KmREZaPRVIdgM7k6MuGwcMGpj8 Wuk2p3fQka3A== X-IronPort-AV: E=McAfee;i="6000,8403,9803"; a="158248592" X-IronPort-AV: E=Sophos;i="5.77,475,1596524400"; d="scan'208";a="158248592" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2020 05:37:44 -0800 IronPort-SDR: qfPd63oDbHJ+QFUJqHY6NNuX8RBeWdVtOV/FE/hkJTkfhbp4NuQl2y1zoEbocJcoUVpU/uR8+c b6uVYExJINeA== X-IronPort-AV: E=Sophos;i="5.77,475,1596524400"; d="scan'208";a="542657881" Received: from ddalessa-mobl.amr.corp.intel.com (HELO [10.254.205.99]) ([10.254.205.99]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Nov 2020 05:37:42 -0800 Subject: Re: [PATCH for-rc v2] IB/hfi1: Move cached value of mm into handler To: Ira Weiny Cc: jgg@ziepe.ca, dledford@redhat.com, Jann Horn , linux-rdma@vger.kernel.org, Mike Marciniszyn , linux-mm@kvack.org, Jason Gunthorpe References: <20201112025837.24440.6767.stgit@awfm-01.aw.intel.com> <20201112171439.GT3976735@iweiny-DESK2.sc.intel.com> <20201113003357.GW3976735@iweiny-DESK2.sc.intel.com> From: Dennis Dalessandro Message-ID: Date: Fri, 13 Nov 2020 08:37:39 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201113003357.GW3976735@iweiny-DESK2.sc.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000021, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 11/12/2020 7:33 PM, Ira Weiny wrote: > So I think the final point is the key to fixing the bug. Keeping any > current->mm which is not the one we opened the file with... (or more > specifically the one which first registered memory). In some ways this may be > worse than before because technically the parent could open the fd and hand it > to the child and have the child register with it's mm. But that is ok > really... May just be odd behavior for some users depending on what operations > they do and in what order. I don't think that's worse than before. Before we were letting it operate on the wrong mm. That's so much worse. Yes, parent could open fd and hand it off, which is OK. The "odd" behavior is up to whoever wrote the user space code to do that in the first place. > [1] Also, you probably should credit Jann for the idea with a suggested by tag. Will change reported-by to suggested-by. -Denny