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 45F20368961; Sat, 28 Feb 2026 06:50:42 +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=1772261442; cv=none; b=ZOT8Qt11kjrKs5yFcxfb6wlkhUQW8MKwDso7iwOkpIz8bQqjokKEnrAuodEnmqDJSFVVSCQl4YIUnYsTD5FlkL9w2Ky9IwnWofF486X1FVp2GkNAfSPKW4NdL7WJKSjiGS1g+QVxpyTLXUyHUTbSdm1pjhXzi4dLkMKel02H5Hc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772261442; c=relaxed/simple; bh=vPTEPlrxe6ytedqa6Me+M+hZkV+rGO8rrN4LIEvszKU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EBrb+OIC5dybyKqJX7IwTQa46uEC/cVSYw2SLS6BACPM9zeIeHWE1q8ZTjOH3b6lzAHeFwincqCKqHdwE3YGtSEgbnyDnK65y1UL6A9q7vnralb5jb7OohtkYF/07hXMdX0RsxUq72N8MwBK3e0/5rVSIKR3F8FjljNH5LvUg78= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iTFfr8oc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iTFfr8oc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 11F92C116D0; Sat, 28 Feb 2026 06:50:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772261441; bh=vPTEPlrxe6ytedqa6Me+M+hZkV+rGO8rrN4LIEvszKU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=iTFfr8ocKEvs3vXYRewYWPSFe2kL3EkPqlXMH9SFlbuxla7B1++TfbbR29cAr/T69 8RlajaFDOInAOiN+ZK7veFCGRmxjx3J7bE/ObG1rUVu/wJzBNzB68455fQxxkndpm2 Tm8vLFnkUPRX5ZN0PkWUIEMTd4tfYl/XR8pSy9Z/UPR0Qpq83+piDFPoy0+TgckjTx fIBVNpnimUABvVb4nGDJC3hmwuwMOJKdRSInNWdlSTmxsPRa6fXgS00DoHU0JgsDRW lp50vbyxlZIuxosoVMrxCRj/2aCgMhGTMqw6gfvTpMznmcYFwDNIHqHcgooJXMIogZ UhhsWMu+jeEcw== Date: Fri, 27 Feb 2026 22:50:38 -0800 From: Eric Biggers To: Christoph Hellwig Cc: Andrew Morton , Richard Henderson , Matt Turner , Magnus Lindholm , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Madhavan Srinivasan , Michael Ellerman , Nicholas Piggin , "Christophe Leroy (CS GROUP)" , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Christian Borntraeger , Sven Schnelle , "David S. Miller" , Andreas Larsson , Richard Weinberger , Anton Ivanov , Johannes Berg , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , Herbert Xu , Dan Williams , Chris Mason , David Sterba , Arnd Bergmann , Song Liu , Yu Kuai , Li Nan , linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, sparclinux@vger.kernel.org, linux-um@lists.infradead.org, linux-crypto@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-arch@vger.kernel.org, linux-raid@vger.kernel.org Subject: Re: [PATCH 21/25] xor: add a better public API Message-ID: <20260228065038.GH65277@quark> References: <20260226151106.144735-1-hch@lst.de> <20260226151106.144735-22-hch@lst.de> Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260226151106.144735-22-hch@lst.de> On Thu, Feb 26, 2026 at 07:10:33AM -0800, Christoph Hellwig wrote: > xor_blocks is very annoying to use, because it is limited to 4 + 1 > sources / destinations, has an odd argument order and is completely > undocumented. > > Lift the code that loops around it from btrfs and async_tx/async_xor into > common code under the name xor_gen and properly document it. > > Signed-off-by: Christoph Hellwig > --- > include/linux/raid/xor.h | 3 +++ > lib/raid/xor/xor-core.c | 28 ++++++++++++++++++++++++++++ > 2 files changed, 31 insertions(+) > > diff --git a/include/linux/raid/xor.h b/include/linux/raid/xor.h > index 02bda8d99534..4735a4e960f9 100644 > --- a/include/linux/raid/xor.h > +++ b/include/linux/raid/xor.h > @@ -7,4 +7,7 @@ > extern void xor_blocks(unsigned int count, unsigned int bytes, > void *dest, void **srcs); > > +void xor_gen(void *dest, void **srcss, unsigned int src_cnt, > + unsigned int bytes); srcss => srcs Ideally the source vectors would be 'const' as well. > +/** > + * xor_gen - generate RAID-style XOR information > + * @dest: destination vector > + * @srcs: source vectors > + * @src_cnt: number of source vectors > + * @bytes: length in bytes of each vector > + * > + * Performs bit-wise XOR operation into @dest for each of the @src_cnt vectors > + * in @srcs for a length of @bytes bytes. > + * > + * Note: for typical RAID uses, @dest either needs to be zeroed, or filled with > + * the first disk, which then needs to be removed from @srcs. > + */ > +void xor_gen(void *dest, void **srcs, unsigned int src_cnt, unsigned int bytes) > +{ > + unsigned int src_off = 0; > + > + while (src_cnt > 0) { > + unsigned int this_cnt = min(src_cnt, MAX_XOR_BLOCKS); > + > + xor_blocks(this_cnt, bytes, dest, srcs + src_off); > + > + src_cnt -= this_cnt; > + src_off += this_cnt; > + } > +} > +EXPORT_SYMBOL(xor_gen); The alignment requirements on the vectors should be documented, as should which values of bytes are accepted. It looks like, at the very least, the vectors have to be 32-byte aligned and the length has to be a nonzero multiple of 512 bytes. But I didn't check every implementation. Also, the requirement on the calling context (e.g. !is_interrupt()) should be documented as well. - Eric