Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3224027imu; Sat, 24 Nov 2018 00:30:03 -0800 (PST) X-Google-Smtp-Source: AJdET5fJEWcMNlebHYM9zqMGdvQ9zA9xsqHKFGzNJ0AQbI3wyP+8BtxVi2bWoOIbhl2Grn79sSIu X-Received: by 2002:a62:ce0e:: with SMTP id y14mr20121949pfg.100.1543048203722; Sat, 24 Nov 2018 00:30:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543048203; cv=none; d=google.com; s=arc-20160816; b=AMxmMYxfXnzxFRTBfcCu8FhfeN2hkTi422Yli17lgzvbFz6fES8pE/zIFxWgdmtAH3 YaH0mqjgl2ubY0Eq2I1NMuRbwhTBeDTUx27ReY779C6Vf+fOqms73oXaDrW7oMZkBHly KmKEShVXBgOcvm3AJO0/BwBe2YiyqSyWBC71RHw/pIHVNTF/+/6kUJMBTSRBd8irMQho ev2+60+CUuNNUggRhKdtbqbspQga6Xf4Rao1W0ktBjyxhOEfNki5dmMkGL1kuJ1UIlw0 EzFU49YE/sMIWCzO0E7yLGQd13nA4/t5jVOCl5q1/uM71DuDG6JnhEezhrRbbjhp+uSp mw5Q== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=Mzpc+iuzYiyMygzlioQu7423NsCICzYMgH1k4zS5gyY=; b=U9sMeVxAlNaO4PCwvPfc9VIaUpRwhtf4XKYO5Y87gLdnBc5mmEmDbQOFK4Zoky2sKa w1ij9KpyM123JZryZtb41SUGBCfSXAZmA2hkmBse1TX41x4f1pShaPDExKJogk2vAmDK VRYWC9bF1vF0Hl55FUyGBOX9pcRn6uspO0hDaMMXF9AD2jgIDgJCJ6HRWj57U/4kn8Y+ cwVGjiOCP1isG6fW7URoAqR9a8zNHSOuMa1BwiTb/WYIFcY+Jn+ms2Av+0BSlc6xq64d 9uEbrCCq3y6BUwHKKzfh6a/FJsUGMqKiEdog9pxBoIH8vLZZQWSBKoUEicZwn2PnlaUY jABw== ARC-Authentication-Results: i=1; mx.google.com; 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 d12si46268121pga.506.2018.11.24.00.29.49; Sat, 24 Nov 2018 00:30:03 -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; 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 S2409719AbeKWWlb (ORCPT + 99 others); Fri, 23 Nov 2018 17:41:31 -0500 Received: from foss.arm.com ([217.140.101.70]:42964 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387885AbeKWWlb (ORCPT ); Fri, 23 Nov 2018 17:41:31 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4F5B33620; Fri, 23 Nov 2018 03:57:34 -0800 (PST) Received: from [10.1.197.36] (e112298-lin.cambridge.arm.com [10.1.197.36]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id E7E163F5A0; Fri, 23 Nov 2018 03:57:32 -0800 (PST) Subject: Re: Sleeping in user_access section To: Russell King - ARM Linux , hpa@zytor.com Cc: Ingo Molnar , LKML , "linux-arm-kernel@lists.infradead.org" , Catalin Marinas , Will Deacon , James Morse References: <3e881ee6-0ff6-b8b6-0633-3d4a7743411d@arm.com> <5B3B6AF9-9D8C-4577-905E-D407A5E7D0E3@zytor.com> <20181123105034.GQ30658@n2100.armlinux.org.uk> From: Julien Thierry Message-ID: <44297716-74aa-1f14-67be-3594b5244b74@arm.com> Date: Fri, 23 Nov 2018 11:57:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20181123105034.GQ30658@n2100.armlinux.org.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23/11/18 10:50, Russell King - ARM Linux wrote: > On Fri, Nov 23, 2018 at 01:57:12AM -0800, hpa@zytor.com wrote: >> You should never call a sleeping function from a user_access section. >> It is intended for very limited regions. > > So, what happens if the "unsafe" user access causes a page fault that > ends up sleeping? > Thanks for pointing that out. On the arm64 side, PAN state is saved in spsr and (if PAN feature is enabled in SCTLR) PAN bit gets set (disabling the user accesses). For software PAN we follow the same behaviour on exception entry. So upon exception we implicitly exit user_access mode and then re-enter it when returning from the exception. On x86, the EFLAGS.AC bit is also saved upon exception and I think it is cleared upon exception entry so there is implicit exit from the user_access mode when taking exception/interrupt. This however is just how those two architectures happen to behave and doesn't seem to be specified as part of the user_access API... Which is why I'd like to clarify the semantics of user_access region wrt sleeping functions. Thanks, -- Julien Thierry