Received: by 2002:a05:6a10:6d10:0:0:0:0 with SMTP id gq16csp965136pxb; Fri, 22 Apr 2022 15:28:51 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyjSNvjE9Q61X867UveKy+auzIS5DoCUx9lo7J+4lgQ+0Rlxz2hAQCpBHinDqPFffNtju+a X-Received: by 2002:a62:6443:0:b0:50a:d54c:7de2 with SMTP id y64-20020a626443000000b0050ad54c7de2mr7139496pfb.60.1650666531470; Fri, 22 Apr 2022 15:28:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1650666531; cv=none; d=google.com; s=arc-20160816; b=Nnpq5c5nkFS6jCDw+3toLwqbf91UqvYvkjm78fJeZ98xGKFuK3zYD91/sssCCM2X9k dgQIs7mrlpCDJHpr644+RcRxqLwmDU2f/IGcbd9IPkqxM6pMK/PLXH0WwFA5T8W/VSuI UPTshv1xnEa1WgkXuAGLlZZC6YaU5B2gPa1cYLqfZthZyCnUuman8vZhIx5gv6J+SxYU i6i7Uyxi7FAFhzI+uNPMi3kVqw3jUmNUZEc1ZNGn+mh8+jvw0jB9pEkcXkc8lEk2Zt2I 8UpzjlbYCJ8kBuUNMiy+ebIMjJ3jd27TScYD2SlLzjGewEp8gGNZk+o4gNdka2JHMNRz B7+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=NnvmbBs0qOAJuSiuPt/Kzd+BnN2z0tbfQ1LImWz/2O4=; b=1DY3fjkBMSN5hsHoWs6z7Cjw3VGwa4gv0gDCstkq8F8oFzqJYhEyVmqqlGK1ivaezo d/OexJCW3eSrLtmievB97uKPfUfb4UaLHvPzL/Egp6EU9uRNbgeQs/FUyJJMsvIdR3Gu wjSFPJ0pQpUoBhkSxZeZPxhpxokERwiM7vUDKRHOCsjIE082V3djG6xf/yHRzFkkyiz7 DWTDrIqeBx1WcNDoQn0rh16+ILgpIcRncL842QWOP2t77SKLCizVm3Y8WwmfBHGYQk1O 9S7WnezT+AVgTfeyVdSCZzDq9lZrOTRg7oNOkpVSCDzOvE+ugLZ6NLSVYm0NJQmHppDA JFWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=mEoSPu+8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id j2-20020a635502000000b003aa4cf7f58fsi9096222pgb.136.2022.04.22.15.28.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 15:28:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=mEoSPu+8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 782AC1E5E0C; Fri, 22 Apr 2022 13:36:12 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232732AbiDVSNg (ORCPT + 99 others); Fri, 22 Apr 2022 14:13:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58904 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237548AbiDVSNE (ORCPT ); Fri, 22 Apr 2022 14:13:04 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A748E5D187; Fri, 22 Apr 2022 11:10:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1650651009; x=1682187009; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=HX/ZyQQsLl+UqtREKQBoegBeMaZnDPZSJUdaRvkzaVM=; b=mEoSPu+8mtqzw1UUgwDgJMPdMsXUjamfyAa+fFJvrgmeBo9oyw9SiQU7 v9c5V3JK+S2SbBKU6lALCJ90gESXpxzCLdBGV+UklxW1AbFYjLBOeJwp3 iHTQXmcxF20trDul51aONVHcigLPfwsqXQY5z/nNm5aA8SAmTKLZbrXVJ wwGvzv6RPg77iur7ADkXBW9t/eUI1+cSXI3C7+//vcDkxmt+YbIVWJGU+ bPhl9V1vfuqQWYgsedsVm9ZA/sSPyZohdpGigb135Va2ZZYRQ1/KZEXVd Bwz4M15LegKhfyzMX4Xp4fcmC020w7sP8kWKP12Rmu8pqySZmMOhtMw1X g==; X-IronPort-AV: E=McAfee;i="6400,9594,10324"; a="264521726" X-IronPort-AV: E=Sophos;i="5.90,282,1643702400"; d="scan'208";a="264521726" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2022 11:08:47 -0700 X-IronPort-AV: E=Sophos;i="5.90,282,1643702400"; d="scan'208";a="563138636" Received: from hltravis-mobl1.amr.corp.intel.com (HELO localhost) ([10.213.166.215]) by fmsmga007-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Apr 2022 11:08:46 -0700 Date: Fri, 22 Apr 2022 11:08:46 -0700 From: Ira Weiny To: "Fabio M. De Francesco" Cc: Andrew Morton , Catalin Marinas , "Matthew Wilcox (Oracle)" , Will Deacon , Peter Collingbourne , Vlastimil Babka , Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Jonathan Corbet , linux-doc@vger.kernel.org, outreachy@lists.linux.dev, Mike Rapoport Subject: Re: [PATCH 1/4] mm/highmem: Fix kernel-doc warnings in highmem*.h Message-ID: References: <20220421180200.16901-1-fmdefrancesco@gmail.com> <20220421180200.16901-2-fmdefrancesco@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220421180200.16901-2-fmdefrancesco@gmail.com> X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 21, 2022 at 08:01:57PM +0200, Fabio M. De Francesco wrote: > `scripts/kernel-doc -v -none include/linux/highmem*` reports the following > warnings: > > include/linux/highmem.h:160: warning: expecting prototype for kunmap_atomic(). Prototype was for nr_free_highpages() instead > include/linux/highmem.h:204: warning: No description found for return value of 'alloc_zeroed_user_highpage_movable' > include/linux/highmem-internal.h:256: warning: Function parameter or member '__addr' not described in 'kunmap_atomic' > include/linux/highmem-internal.h:256: warning: Excess function parameter 'addr' description in 'kunmap_atomic' > > Fix these warnings by (1) moving the kernel-doc comments from highmem.h to > highmem-internal.h (which is the file were the kunmap_atomic() macro is > actually defined), (2) extending and merging it with the comment which was > already in highmem-internal.h, and (3) using correct parameter names. > > Cc: Mike Rapoport > Cc: Ira Weiny > Suggested-by: Matthew Wilcox > Signed-off-by: Fabio M. De Francesco > --- > include/linux/highmem-internal.h | 14 +++++++++++--- > include/linux/highmem.h | 15 +++------------ > 2 files changed, 14 insertions(+), 15 deletions(-) > > diff --git a/include/linux/highmem-internal.h b/include/linux/highmem-internal.h > index a77be5630209..b099a08e29d3 100644 > --- a/include/linux/highmem-internal.h > +++ b/include/linux/highmem-internal.h > @@ -236,9 +236,17 @@ static inline unsigned long totalhigh_pages(void) { return 0UL; } > > #endif /* CONFIG_HIGHMEM */ > > -/* > - * Prevent people trying to call kunmap_atomic() as if it were kunmap() > - * kunmap_atomic() should get the return value of kmap_atomic, not the page. > +/** > + * kunmap_atomic - Unmap the virtual address mapped by kmap_atomic() > + * @__addr: Virtual address to be unmapped > + * > + * Unmap an address previously mapped by kmap_atomic() and re-enables > + * pagefaults and preemption. Mappings should be unmapped in the reverse > + * order that they were mapped. See kmap_local_page() for details. > + * @__addr can be any address within the mapped page, so there is no need > + * to subtract any offset that has been added. In contrast to kunmap(), > + * this function takes the address returned from kmap_atomic(), not the > + * page passed to it. The compiler will warn you if you pass the page. > */ > #define kunmap_atomic(__addr) \ > do { \ > diff --git a/include/linux/highmem.h b/include/linux/highmem.h > index 39bb9b47fa9c..c3d562b5f0c1 100644 > --- a/include/linux/highmem.h > +++ b/include/linux/highmem.h > @@ -37,7 +37,7 @@ static inline void *kmap(struct page *page); > > /** > * kunmap - Unmap the virtual address mapped by kmap() > - * @addr: Virtual address to be unmapped > + * @page: Virtual address to be unmapped ^^^^^^^^^^^^^^^ Page Not only was the name wrong but the description of an address is wrong. Other than that LGTM: Reviewed-by: Ira Weiny > * > * Counterpart to kmap(). A NOOP for CONFIG_HIGHMEM=n and for mappings of > * pages in the low memory area. > @@ -145,17 +145,6 @@ static inline void *kmap_local_folio(struct folio *folio, size_t offset); > */ > static inline void *kmap_atomic(struct page *page); > > -/** > - * kunmap_atomic - Unmap the virtual address mapped by kmap_atomic() > - * @addr: Virtual address to be unmapped > - * > - * Counterpart to kmap_atomic(). > - * > - * Effectively a wrapper around kunmap_local() which additionally undoes > - * the side effects of kmap_atomic(), i.e. reenabling pagefaults and > - * preemption. > - */ > - > /* Highmem related interfaces for management code */ > static inline unsigned int nr_free_highpages(void); > static inline unsigned long totalhigh_pages(void); > @@ -191,6 +180,8 @@ static inline void clear_user_highpage(struct page *page, unsigned long vaddr) > * @vma: The VMA the page is to be allocated for > * @vaddr: The virtual address the page will be inserted into > * > + * Returns: The allocated and zeroed HIGHMEM page > + * > * This function will allocate a page for a VMA that the caller knows will > * be able to migrate in the future using move_pages() or reclaimed > * > -- > 2.34.1 >