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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A53C8E77188 for ; Thu, 2 Jan 2025 22:10:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A7256B00AD; Thu, 2 Jan 2025 17:10:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 156C06B00AE; Thu, 2 Jan 2025 17:10:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0448A6B00B2; Thu, 2 Jan 2025 17:10:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id DFA1E6B00AD for ; Thu, 2 Jan 2025 17:10:19 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 6ACBD1604C3 for ; Thu, 2 Jan 2025 22:10:19 +0000 (UTC) X-FDA: 82963903596.01.E0645BA Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 2EFFC1C000F for ; Thu, 2 Jan 2025 22:09:25 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="fGu0rQ/V"; dmarc=none; spf=pass (imf20.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735855770; a=rsa-sha256; cv=none; b=BPus/Q0R+nc+QQB4NJ9LUvv4AxFlek1P3Pno/ESDnbn+6GKAI1bjPYtf0z/zvyofWGrFl3 L2kvRCN3eqaw7+cE4FBQmcJsI1Y8CNUOyKowtHmcB9gMCboUOEakqoRfib4/u4HuHtNWsc MTeu017uHYoSmv7FEwOIebJVH9xr014= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b="fGu0rQ/V"; dmarc=none; spf=pass (imf20.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735855770; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=zW5IA+wZ/82nxABKWDwq/2FhNaZ/7hmDECPr0YA0Kls=; b=spabJNqBLrmYNJNNzf4TV5OdgSVBq+2A271rsVg0D23FopB8w84nBgqJcaHT1xp4kCnBaU za78UGuDk1btd7FyUdIdCoxF9NzaVv4imo0yPxwJO4ooBbNkHw8aRLDfN4haa+yqoifLpb bGLWza8kp7h6e0fPndTgw2xOaC81SHY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 394C75C5F77; Thu, 2 Jan 2025 22:09:35 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0D5FFC4CED0; Thu, 2 Jan 2025 22:10:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1735855816; bh=Op4QZsPD+mTAb796tVFKrpeJJG0x3oacxyD2i+fwgrs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=fGu0rQ/VQFtFCzJwHVuAD0Ld+u+M+CNUwur8gQsCzoOm/1VZrYO0xfrM2v9fO7naz w3CI1Rsa8vKeYws8Qa/jnP4s2rgPcjac6vJkAP+Qlab/aOpt1/r9xXGR9QCQi4+CIn seis59pc8XEirl6BWuUYGRw3MdpkvG0727rKDvb0= Date: Thu, 2 Jan 2025 14:10:15 -0800 From: Andrew Morton To: Marco Nelissen Cc: "Matthew Wilcox (Oracle)" , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-xfs@vger.kernel.org Subject: Re: [PATCH] filemap: avoid truncating 64-bit offset to 32 bits Message-Id: <20250102141015.bc8ef069a91cfd9664538494@linux-foundation.org> In-Reply-To: <20250102190540.1356838-1-marco.nelissen@gmail.com> References: <20250102190540.1356838-1-marco.nelissen@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: ubytgcxm3srcp8so3o8ss53ebwgd97ew X-Rspam-User: X-Rspamd-Queue-Id: 2EFFC1C000F X-Rspamd-Server: rspam08 X-HE-Tag: 1735855765-665852 X-HE-Meta: U2FsdGVkX18JVHhA5nfPBYkrMbIqHDTbPi+mlpq1mps8J5f9CkGyEN4EtcpCYmzpJmkUuKwjvd432abrLjYKzc8vSLe5G8N2n/g9NXlA/m6efISOEC3gm1pyOh+9RQiHjMVl/Mu8l5Wyw95JWm16GpG5BXm6sosDECnOZ5TytavQAAd89RyrFAlMNzaX7ThhcTvAiGMYRomu62gzFZbHQRqxyBnfpdJQHeSHRdUfWYTzwtF4d1NIoBcryATYtCYTq4QXYVoBD876EQnhp4a0h7I4mMteyXLHiAFpDQFkpkfguG0bMkuiIdCdFSQ/87nobfebYrC65jqscztTiuQNRVy8H8WVWpYuVXkqYaB8T83U2yg2uTss1aD//dDmrzA5lcvw6uWduTTaC2m7UiWPy7S8Q7TU6xyl1F0bCD1EWQeiW6WR5awdGwqzJlH09KuF2kyKn78AID2SbFXMgquFWy0Eo1WhxzmsIXEPxmszDfh16GifNcTRw7V4i6BzU2xdtso3+guT0ghsxczulAIa86+FfsTUh4RCTPp01bgsXdmlTVb9lfJyCK04bKf+MfzM+hKwzwFUy92V94y6DEaIc9nG6rScjTxp5njB+G3HajJYA7IMtKNHxi2DJCgzAQwv+ld/DsELCNYw5xUN0UspIT+6S3vjyDnKmNYRj+GOlxUGPTjYg637FOD5DzNLKFK0aESr+8hcXWzSroRd9BK1MFYNJC0uE0Ry0ccfshUMPCXUnSHYPvB0ZrS8xNcww4q/glcD5rH6JGDscZFVlG+m5MdvbRCmw1l4trRgLfdBOWBgvlyDZl5MM10Cba0Ih9LocA2p0U7xF4Vsy+Db+S3F8cAfDSkdRR/4125C4O/dQUHnx5DeEeuDFiyNxJb3dqIq1NOVmSPryMk6MVkLCju8Jgbdr54o0FMbDGTVix0mpWTY33Rg2RddZGCPu3pHzXB8pZxocaq9XlDiPwDS7Uo 01M4GdvT ZydRoLPS+pzZOmTPuOCz2556kr3BOzUDD1m1iVZfZuTED/WwQ2g1jNF+BKanXi4Bgc8VQNmhDFVCm1yDqumwysWZ4eCDcusJg906TESLpj8dom4ZVy0/feZUtakBEWyUARpeL2Nu0MKEjPfgOO+lkxP3UgPX9eKXOFDIkWcDqnv3MqUDD1uwQQ55gixLjMs+T2Bq0JsnA87BAz27vS9H4mlfzeCNuWOVQ8cdfDF+YMK3/Jufb2ztpWH0jvrWLBk3YhHz4pWZQNMtAldueLRUYSaDa/oNcrnaPaHSCYGdZd0+R4LB4FiUiLT+ojx+Z57tj+fX2/cUeA5Kz6JfuPIkOdrj2jcMLdGbDwcq/Y1S7cnjajoI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, 2 Jan 2025 11:04:11 -0800 Marco Nelissen wrote: > on 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a > 64-bit value to 32 bits, leading to a possible infinite loop when writing > to an xfs filesystem. > > ... > > +++ b/mm/filemap.c > @@ -3005,7 +3005,7 @@ static inline loff_t folio_seek_hole_data(struct xa_state *xas, > if (ops->is_partially_uptodate(folio, offset, bsz) == > seek_data) > break; > - start = (start + bsz) & ~(bsz - 1); > + start = (start + bsz) & ~((u64)bsz - 1); > offset += bsz; > } while (offset < folio_size(folio)); > unlock: Thanks. I'll add Fixes: 54fa39ac2e00b ("iomap: use mapping_seek_hole_data") Cc: The offset = offset_in_folio(folio, start) & ~(bsz - 1); a few lines earlier is worrisome. I wonder if we should simply make `bsz' and `offset' have type u64 and sleep well at night.