From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 866FC39F18A for ; Fri, 27 Mar 2026 06:32:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774593144; cv=none; b=cBg5kL7KbIW5P3iVN53UDzGhqlcH38Xgk8awef+LHUMPPUUoFVnx++YVOBq9KHmfGWExZ9MGcNcLxnaoky/YeLuTNygQ8KgJkcmcpZ+3wtE8TzqsLeQyNa+8siIZytA8dzc4joaBNvGoUA/v9lV1rbexJ83MizGLzqABjEil6ow= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774593144; c=relaxed/simple; bh=21/vliRDRKtbFZz03Jxj2YlSHmox3eBSlnY147e2h5s=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=qr04FadpHpxjfHF4wkLjzxSO6imMEsz4eLGY6g47aqTIYExUco54I1FFY5M08DShTQhCHvn+2ourw8Zg7it5qxLaQnT7+ekT7kAiNYsfwDFQtc/Ms3m2a5Rm8Sr9E8o6t5pTE1NTfRhr1BlMG+mkWJFxk0wzVkE1VI2Ln+3Rs44= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=oRXHaPXT; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="oRXHaPXT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 49CC0C19423; Fri, 27 Mar 2026 06:32:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1774593143; bh=21/vliRDRKtbFZz03Jxj2YlSHmox3eBSlnY147e2h5s=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=oRXHaPXTDhFLdjDKwU8xl/jVRjlXkD6B/nI5CfERmQmdJ7iU34b4+GNfnpB/TRqUf 7W1r+VCvm/7HVOjpblotFi886eXGEt4lhXE2E3y+xKiDMT0CkZhf20XYaX5yxHjvs2 TnehIRFVeIHAFF7AwUFKsntNDkE6ryI5kzxteKi0= Date: Thu, 26 Mar 2026 23:32:22 -0700 From: Andrew Morton To: Kexin Sun Cc: kees@kernel.org, tony.luck@intel.com, gpiccoli@igalia.com, urezki@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, julia.lawall@inria.fr, xutong.ma@inria.fr, yunbolyu@smu.edu.sg, ratnadiraw@smu.edu.sg Subject: Re: [PATCH] mm: vmalloc: update outdated comment for renamed vread() Message-Id: <20260326233222.a74ea3c13fce2acfa1d37e37@linux-foundation.org> In-Reply-To: <20260321105820.7134-1-kexinsun@smail.nju.edu.cn> References: <20260321105820.7134-1-kexinsun@smail.nju.edu.cn> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sat, 21 Mar 2026 18:58:20 +0800 Kexin Sun wrote: > The function vread() was renamed to vread_iter() in commit > 4c91c07c93bb ("mm: vmalloc: convert vread() to vread_iter()"), > converting from a buffer-based to an iterator-based interface. > > Update the kdoc of vread_iter() to reflect the new interface: > replace references to @buf with @iter, drop the stale "kernel's > buffer" requirement, and update the self-reference from vread() > to vread_iter(). > > Also update the stale vread() reference in pstore's ram_core.c. > LGTM, thanks. > > diff --git a/fs/pstore/ram_core.c b/fs/pstore/ram_core.c > index ed97494abf60..738283a85ea2 100644 > --- a/fs/pstore/ram_core.c > +++ b/fs/pstore/ram_core.c > @@ -450,7 +450,7 @@ static void *persistent_ram_vmap(phys_addr_t start, size_t size, > pages[i] = pfn_to_page(addr >> PAGE_SHIFT); > } > /* > - * VM_IOREMAP used here to bypass this region during vread() > + * VM_IOREMAP used here to bypass this region during vread_iter() > * and kmap_atomic() (i.e. kcore) to avoid __va() failures. > */ > vaddr = vmap(pages, page_count, VM_MAP | VM_IOREMAP, prot); > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 61caa55a4402..9ee256884f78 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -4575,20 +4575,20 @@ static size_t vmap_ram_vread_iter(struct iov_iter *iter, const char *addr, > * @count: number of bytes to be read. > * > * This function checks that addr is a valid vmalloc'ed area, and > - * copy data from that area to a given buffer. If the given memory range > + * copy data from that area to a given iterator. If the given memory range I'll sneak-edit this to read "copies data". > * of [addr...addr+count) includes some valid address, data is copied to > - * proper area of @buf. If there are memory holes, they'll be zero-filled. > + * proper area of @iter. If there are memory holes, they'll be zero-filled. > * IOREMAP area is treated as memory hole and no copy is done. > * > * If [addr...addr+count) doesn't includes any intersects with alive > - * vm_struct area, returns 0. @buf should be kernel's buffer. > + * vm_struct area, returns 0. > * > - * Note: In usual ops, vread() is never necessary because the caller > + * Note: In usual ops, vread_iter() is never necessary because the caller > * should know vmalloc() area is valid and can use memcpy(). > * This is for routines which have to access vmalloc area without > * any information, as /proc/kcore. > * > - * Return: number of bytes for which addr and buf should be increased > + * Return: number of bytes for which addr and iter should be advanced > * (same number as @count) or %0 if [addr...addr+count) doesn't > * include any intersection with valid vmalloc area > */ Things like `addr' and `count' should be `@addr' and `@count', but that's a differnt patch. And we probably make this mistake in a zillion other places.