From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=95.215.58.2 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794563128; b=jVmSxsau+e8tKexWI1FGiU7QfakdJgvR/2w4v1AJ5WRuHtMfnQ0PAhy/IYv8iYRJk7m3 3Na6wojlYmf2XjeyhWWv78tNoJQ9QT+b7HpM/kXuPd7yHGcw5cMSeNEWxIDtZ7dQcZC2b bBaV9KgexngSiUqaE6+OW8C06m1/qLf89LMn4En3yMCPIn2C+sGGix6608k2ijKXecCDU 0cp5R5bs2Q4J7kr6pv8sIZv7Cy7TjnSVAbhOF8DdfFd/mLFlrKiUUw/GQ9J8aEVTwspTO 99SOIwPYilvROW+yk9pHrQje9pnH4ndnnVXDjZMcwEgCRVsWbTI6xdH+TXyqWfUkExw== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794563128; h=DMARC-Filter:X-Envelope-To:DKIM-Signature:X-Envelope-To:Received: X-Mizu-Trace-ID:X-Migadu-Flow:Message-ID:Date:MIME-Version:User-Agent: Subject:To:Cc:References:Content-Language:From:In-Reply-To: Content-Type:Content-Transfer-Encoding; bh=9maGvXRQaCNT3iGa6KnlcrBKjyNiCGaT2SKE8+5ppl4=; b=Su3FytqSlRWT0sA5/6/Gdtjz2Z1LPKA0D8ggSCt8ljhTdjhlWiwPRxA2XNUqyhSZf9i0 dPaqQiFhGWB2+dnfWnAx8zHfH5RfY4Nt2+5mz+dVpRgzO0rPf0OO1wRIePOvwsEYh/7MO nrrxvNtgx6PsyEmhXl0WPm8zrci1uWzOxwhCs2jCaEY7CtWpyNwMCS+3XLLwIBrCHz017 kpWdIXregqbKpkGTr0WoOGAFA1CAfuo36r0TSwx+abACP0Nq3wX7pDU6VgaqjV4PPGWC3 cePdkorJmi2Fyb4M95uALHkuTvKFui00UFkhmp2TKqhtSowm0GAzZ0Pl0Whj3BuTWfA== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=jip9eZGS; arc=none smtp.remote-ip=95.215.58.2 Received: from mta1.migadu.com (out-2.mta1.migadu.com [95.215.58.2]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BD8A2606A321 for ; Fri, 13 Nov 2026 09:45:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org BD8A2606A321 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256 header.s=key1 header.b=jip9eZGS X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=tIt5W2yVysz0C6c0WiAUoXuFquyWfvrCJVtGSZUAG24=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1794563125; v=1; x=1795167925; b=jip9eZGS/7BUvWkGb74HfK2H5pbNNeXMIgaJbJ1oY+EnRpu6kuveUvwdGoeX3TDJmrkqZoK8 QLiWPq7JBxUYq0ekXWC3hwsdH8BTX6rtI4bXBdgV0lZkl3+g9gBs+sZU0fHe5JGxXWIOTisu4m/ 7CSPpUqS5/8y460L0NGpUPh8= X-Envelope-To: linux-kernel@vger.kernel.org Received: by mta12.migadu.com with ESMTPS id 3056ac4d99aaa11e; Fri, 13 Nov 2026 09:45:23 +0000 X-Mizu-Trace-ID: 3056ac4d99aaa11e X-Migadu-Flow: FLOW_OUT Message-ID: Date: Fri, 13 Nov 2026 09:45:22 +0000 X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: (2) [PATCH v2] xfs: check the disk address for hardware atomic writes To: daejun7.park@samsung.com, Carlos Maiolino , "linux-xfs@vger.kernel.org" Cc: Pankaj Raghav Partha Sarathy , Pankaj Raghav , "Darrick J. Wong" , Christoph Hellwig , Dave Chinner , "linux-kernel@vger.kernel.org" References: <20261112-xfs-hw-atomic-align-v2-1-c90394805e7b@samsung.com> <20261113025544epcms2p575490538b97c26387515f8b5fc90c321@epcms2p5> Content-Language: en-US From: John Garry In-Reply-To: <20261113025544epcms2p575490538b97c26387515f8b5fc90c321@epcms2p5> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/13/26 02:55, Daejun Park wrote: > On Thu, Nov 12, 2026 at 08:29:42AM +0000, John Garry wrote: >> On 11/12/26 00:41, Daejun Park via B4 Relay wrote: > [...] >>> - if (!IS_ALIGNED(imap->br_startblock, imap->br_blockcount)) >> Is there anywhere else in which we do an alignment check on >> br_startblock that relies on the group size to be a multiple of the HW >> awu max? > No, I did not find another one. This is the only check of the start > block for the REQ_ATOMIC path. Two other places depend on the group > alignment, but neither checks br_startblock: > > - xfs_get_atomic_write_max_opt() already caps max_opt at > xfs_calc_group_awu_align_max(), the largest power-of-two factor of > the group size (from ec8f62cc109a). > - The allocator aligns the AG block number, not the disk address, > for example for XFS_BMAPI_EXTSZALIGN in > xfs_atomic_write_cow_iomap_begin(). In an unaligned AG, that extent > can still be misaligned on disk. With this patch, the next atomic > write to it goes through COW instead of failing. hmm.. I am still not confident that this the best fix. And if it is, then I think that we should still change the size pre-check in xfs_file_dio_write_atomic(). Here's a combined change which I am thinking of: --- a/fs/xfs/xfs_file.c +++ b/fs/xfs/xfs_file.c @@ -776,7 +776,7 @@ xfs_file_dio_write_atomic( * HW offload should be faster, so try that first if it is already * known that the write length is not too large. */ - if (ocount > xfs_inode_buftarg(ip)->bt_awu_max) + if (ocount > xfs_get_atomic_write_max_opt()) dops = &xfs_atomic_write_cow_iomap_ops; else dops = &xfs_direct_write_iomap_ops; diff --git a/fs/xfs/xfs_iomap.c b/fs/xfs/xfs_iomap.c index c3465204b8d5..c54aaa4b8816 100644 --- a/fs/xfs/xfs_iomap.c +++ b/fs/xfs/xfs_iomap.c @@ -863,7 +863,7 @@ xfs_bmap_hw_atomic_write_possible( /* * The ->iomap_begin caller should ensure this, but check anyway. */ - return len <= xfs_inode_buftarg(ip)->bt_awu_max; + return len <= xfs_get_atomic_write_max_opt(); } bt_awu_max is the HW max, and you are saying that it is not aligned with the AG size (and so need a disk alignment check). However, opt max should be (aligned to AG size), so we could check that vs size instead. Note that I am just using xfs_get_atomic_write_max_opt() for illustrative purposes and we could save this value in xfs_inode_buftarg(). BTW, with your proposed change, since HW size is not aligned to AG size and we only check the size vs HW size for HW offload, it is in theory possible to have an atomic write which straddles the AG and is rejected, right? Thanks, John