Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp811550ybk; Wed, 13 May 2020 13:49:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzYWFkxl7q34aYmZGt6DjZhCbsmfTm7OIRW51agSiUoj8PO8vWmPdvu0M6NNNHdHxHDvmD3 X-Received: by 2002:a50:c3c2:: with SMTP id i2mr1308851edf.93.1589402985900; Wed, 13 May 2020 13:49:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589402985; cv=none; d=google.com; s=arc-20160816; b=BPhiannGGcSKPb0/FRg9QMATqSEnpVNEC37mOxZ5JV29We5wnb6/D6+iOQFoJW1by0 aKjTMdGRre67TEutHhwPYWuUZ942AzjNFI4WJe/FTcMbSstxnhPeWxXSXoRfYp1yTiZ5 LYMWz1UsrgqZBp4PZTnU5iizb4O96ozNwHjblZJmWxiPt8XtHJjEuVvjk+jNWVBFaNvG 89Z6Q7RvX2PveYwu119Fu9yVK0KOGG7f24QV6Q8JUQLGtY0KZZ/c8ElUrPOyWarkVdY/ n2AUEkfXRnaQ7oZ2usJJVR8w0+tpqJXOMAVVQKvgMTpd6y3fV4GewcNjk+A7rSXDMWKF ajMw== 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 :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=mSMXwSYIg6w8Djb8jfs2EjgdqI2tqBJvsH4pyf4a+s4=; b=mesf96ssDMSEaM/92MexkCvrBcTaySS2IztFYosWkp1QW7ejFgS+Kb3AKwk8TKOiPY EzOIhBfLD64ApdGqpyFwZkR37ZkMTh3DyXqbnj82yKGM3lsYD+uxcOvA6YT9wqQSzCld 059IQCMeKb9Ei1adxxw3eUrDxEGRcFu1pWgX1yR5N2EICmguqdULYXP2gG7KHbSLngjd E1WyRD5QpWI5weqvM72R3P62tztL5QuoFCToQAJ1tXTOl7PXsBE3bvb8wd1BNLG+suQn 85qe9yk9+olEIEon5m+x+gFHrG+noYRqPI3gaqU63eIdVdXLaqTt5B/rq3Azrf1jYMcL k2Sw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=K7vXcJeQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id dc9si470898ejb.370.2020.05.13.13.49.23; Wed, 13 May 2020 13:49:45 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=K7vXcJeQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389382AbgEMQAz (ORCPT + 99 others); Wed, 13 May 2020 12:00:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50756 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389348AbgEMQAx (ORCPT ); Wed, 13 May 2020 12:00:53 -0400 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:e::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB682C061A0C; Wed, 13 May 2020 09:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From:Sender :Reply-To:Content-Type:Content-ID:Content-Description; bh=mSMXwSYIg6w8Djb8jfs2EjgdqI2tqBJvsH4pyf4a+s4=; b=K7vXcJeQdZ4RxFlFwWFM087V2s ELGL5A58AHOSBzKj7tSKyX1/5d/XvhoN/lFQJNE8Ml8PL7igR4gDP0nge0LibB2gH9sYX5OPVbtRV XsCsiBJYRNog7EKtYR2j8v3RYS7UaXLJPMfeuVRw3DkSpo4rga4+m4uPkRWfT1yDlkmSNOKnpNw7/ DXby0rgCEtH1QjbS7puSqf7dUsnzCY0wQEzDivuEktT3SVj643l7vgfi7h8f+lE226/hsFFsRa8ri LtYKe2R97TArhfTeE8v4HwzdzypRNsAiSvWdvbhYUyq5tW10XFMdVgovAN/qZzCyyLB+F4CeycFLP zl+XNRDg==; Received: from [2001:4bb8:180:9d3f:c70:4a89:bc61:2] (helo=localhost) by bombadil.infradead.org with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1jYtoR-0004j2-24; Wed, 13 May 2020 16:00:51 +0000 From: Christoph Hellwig To: x86@kernel.org, Alexei Starovoitov , Daniel Borkmann , Masami Hiramatsu , Linus Torvalds , Andrew Morton Cc: linux-parisc@vger.kernel.org, linux-um@lists.infradead.org, netdev@vger.kernel.org, bpf@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH 04/18] maccess: clarify kerneldoc comments Date: Wed, 13 May 2020 18:00:24 +0200 Message-Id: <20200513160038.2482415-5-hch@lst.de> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200513160038.2482415-1-hch@lst.de> References: <20200513160038.2482415-1-hch@lst.de> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Add proper kerneldoc comments for probe_kernel_read_strict and probe_kernel_read strncpy_from_unsafe_strict and explain the different versus the non-strict version. Signed-off-by: Christoph Hellwig --- mm/maccess.c | 61 ++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 43 insertions(+), 18 deletions(-) diff --git a/mm/maccess.c b/mm/maccess.c index 4e7f3b6eb05ae..747581ac50dc9 100644 --- a/mm/maccess.c +++ b/mm/maccess.c @@ -31,29 +31,35 @@ probe_write_common(void __user *dst, const void *src, size_t size) } /** - * probe_kernel_read(): safely attempt to read from a kernel-space location + * probe_kernel_read(): safely attempt to read from any location * @dst: pointer to the buffer that shall take the data * @src: address to read from * @size: size of the data chunk * - * Safely read from address @src to the buffer at @dst. If a kernel fault - * happens, handle that and return -EFAULT. + * Same as probe_kernel_read_strict() except that for architectures with + * not fully separated user and kernel address spaces this function also works + * for user address tanges. + * + * DO NOT USE THIS FUNCTION - it is broken on architectures with entirely + * separate kernel and user address spaces, and also a bad idea otherwise. + */ +long __weak probe_kernel_read(void *dst, const void *src, size_t size) + __attribute__((alias("__probe_kernel_read"))); + +/** + * probe_kernel_read_strict(): safely attempt to read from kernel-space + * @dst: pointer to the buffer that shall take the data + * @src: address to read from + * @size: size of the data chunk + * + * Safely read from kernel address @src to the buffer at @dst. If a kernel + * fault happens, handle that and return -EFAULT. * * We ensure that the copy_from_user is executed in atomic context so that * do_page_fault() doesn't attempt to take mmap_sem. This makes * probe_kernel_read() suitable for use within regions where the caller * already holds mmap_sem, or other locks which nest inside mmap_sem. - * - * probe_kernel_read_strict() is the same as probe_kernel_read() except for - * the case where architectures have non-overlapping user and kernel address - * ranges: probe_kernel_read_strict() will additionally return -EFAULT for - * probing memory on a user address range where probe_user_read() is supposed - * to be used instead. */ - -long __weak probe_kernel_read(void *dst, const void *src, size_t size) - __attribute__((alias("__probe_kernel_read"))); - long __weak probe_kernel_read_strict(void *dst, const void *src, size_t size) __attribute__((alias("__probe_kernel_read"))); @@ -153,15 +159,34 @@ long probe_user_write(void __user *dst, const void *src, size_t size) * If @count is smaller than the length of the string, copies @count-1 bytes, * sets the last byte of @dst buffer to NUL and returns @count. * - * strncpy_from_unsafe_strict() is the same as strncpy_from_unsafe() except - * for the case where architectures have non-overlapping user and kernel address - * ranges: strncpy_from_unsafe_strict() will additionally return -EFAULT for - * probing memory on a user address range where strncpy_from_unsafe_user() is - * supposed to be used instead. + * Same as strncpy_from_unsafe_strict() except that for architectures with + * not fully separated user and kernel address spaces this function also works + * for user address tanges. + * + * DO NOT USE THIS FUNCTION - it is broken on architectures with entirely + * separate kernel and user address spaces, and also a bad idea otherwise. */ long __weak strncpy_from_unsafe(char *dst, const void *unsafe_addr, long count) __attribute__((alias("__strncpy_from_unsafe"))); +/** + * strncpy_from_unsafe_strict: - Copy a NUL terminated string from unsafe + * address. + * @dst: Destination address, in kernel space. This buffer must be at + * least @count bytes long. + * @unsafe_addr: Unsafe address. + * @count: Maximum number of bytes to copy, including the trailing NUL. + * + * Copies a NUL-terminated string from unsafe address to kernel buffer. + * + * On success, returns the length of the string INCLUDING the trailing NUL. + * + * If access fails, returns -EFAULT (some data may have been copied + * and the trailing NUL added). + * + * If @count is smaller than the length of the string, copies @count-1 bytes, + * sets the last byte of @dst buffer to NUL and returns @count. + */ long __weak strncpy_from_unsafe_strict(char *dst, const void *unsafe_addr, long count) __attribute__((alias("__strncpy_from_unsafe"))); -- 2.26.2