From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from m16.mail.126.com (m16.mail.126.com [117.135.210.9]) (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 211D739A807; Wed, 9 Sep 2026 07:41:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=117.135.210.9 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788939684; cv=none; b=UcFozc4EllOeIT6YlzEYe/8K2I8C7Ry6qGHgFczx1uWxmUzTLTHbbvDJCl1+Hz87n49L3zrLQ+kmRhfaZ4OVkeVcEnBAG2KvG5b6+6ij9Po2UcGcI4En8sLdTKTQky151I7OYnd2Lwhn6pZA1sH0nwsO5nRzzmnQbaxPvYaDOFY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788939684; c=relaxed/simple; bh=Y7IMMoAe0P9D+WRSBkVBPj9oQEY3shNsdP/66A1tL4I=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=K27hrBhcayzAAipGuYhoXq+RYh9haDy7V3qDHs8ZRUJnU/6FxcO8s9yuHLxFIldAHjXy69npAZ0SmkcPAk4ZNZuopuJnFX4QNwfa0uYiiIwwqEHIPyLCl049mDLDE+t3q16eyGiZVcsxsXx2607pFu9FpE3BV8qLbDOoiIaPEhM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com; spf=pass smtp.mailfrom=126.com; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b=BQWwQEFN; arc=none smtp.client-ip=117.135.210.9 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=126.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=126.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=126.com header.i=@126.com header.b="BQWwQEFN" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=126.com; s=s110527; h=Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; bh=4mhyiuXHdkylIUvNmVFXSgeIj+5kPbmYba+P1UHgLak=; b=BQWwQEFNU6pIwfslX/GRUvhdQ4UUt//wHQmg4W2mhyqtLR5IsLaO3VXLrzjw9U 3lczSi5mI64qhsqykYJx+aD1VYH4FPQ9LEdlnKKh77wLG8M48kUMNZs/oCI49Sxh 3KxftANAu/oCtYU5srbsorHAVOo1S38HeLeEdjz8UMWUo= Received: from localhost.localdomain (unknown []) by gzsmtp4 (Coremail) with SMTP id PykvCgD3X1yBDaFqM2k+HQ--.2132S2; Wed, 09 Sep 2026 15:40:49 +0800 (CST) Message-ID: <6AA10D61.6030403@126.com> Date: Wed, 09 Sep 2026 15:40:17 +0800 From: Hongling Zeng User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 To: Dave Chinner CC: Hongling Zeng , cem@kernel.org, darrick.wong@oracle.com, chandanrlinux@gmail.com, linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2] xfs: bound logged region access in inode buffer recovery References: <20260907080450.314067-1-zenghongling@kylinos.cn> <6A9F7022.6020206@126.com> <6A9FBDB3.20705@126.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CM-TRANSID:PykvCgD3X1yBDaFqM2k+HQ--.2132S2 X-Coremail-Antispam: 1Uf129KBjvJXoWxAr1UZFy7tF1kWF4kJF1xGrg_yoW5Kr17pF WfKa18urWkJ34IvrykAF48JaySgrZ5Ga9xGr98t34DAFn8KrnxKFWvya1Y9Fy7CrnYg34j vw4jyw4qg34UAaDanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDUYxBIdaVFxhVjvjDU0xZFpf9x07j-WrJUUUUU= X-CM-SenderInfo: x2kr0wpolqwiqxrzqiyswou0bp/xtbBoQJmN2qhDYIqCgAA3W 在 2026年09月09日 07:00, Dave Chinner 写道: > On Tue, Sep 08, 2026 at 03:48:03PM +0800, Hongling Zeng wrote: >> 在 2026年09月08日 14:33, Dave Chinner 写道: >>> Don't take the design doc as being complete or correct - it's a >>> working document and really only serves as the initial high level >>> plan I fleshed out. >>> >>> Indeed, I implemented a chunk of it yesterday afternoon (i.e. >>> before I saw your patch this morning) and my findings change quite a >>> bit of the generic infrastructure to make it handle the transaction >>> header without having to special case it. So from that perspective, >>> it's already out of date... >>> >>> I'll post what I have in the series later this afternoon so you can >>> get up to speed. > Ok, I just posted my current WIP to the log-verification-1 branch in > my kernel.org repo > (https://git.kernel.org/pub/scm/linux/kernel/git/dgc/linux-xfs.git) > > This is completely untested, I've only made sure it compiles. Don't > expect it to work. If you do start adding to it, build on top of it > and point me to the git repo where all your new work can be found. > > What I've implemented so far is the refactoring necessary to > implement generic handling of log item verification and decoding, > converted the special case transhdr decoding to use the generic > infrastructure, and implemented fairly complete ophdr validation, > including validation of the log unmount record (which isn't > validated in any way right now). > > Design has changed to use methods for item specific region count > checking, as well as adding a completion method that allows item > types to consume the item rather than queuing it for later recovery > (both needed for the transhdr conversion). Implementation has been > refined to avoid decoding ophdrs until sufficient validation has > been performed to guarantee the buffer pointer is sane and is long > enough to contain a full ophdr, and then it valdates the rest of the > ophdr before passing it to the processing code. > > The next steps are to start implementing the per-item type > validation functions. > > I also noticed that the head/tail search code that reads log > record headers doesn't really do much validation on the log record > headers. We probably need to address that, too, so we can detect > corrupted headers during the head/tail search and avoid finding > incorrect head/tail records as a result. > >> Once your series is posted I'll start with review and the >> recoveryloop / logprint-based testing, then take the per-type >> validate_region() / validate_item() implementations on top of your >> iterator. > I think it's probably better that you first read the code yourself > and develop an understanding of what needs to be done without the > aid of an LLM. See if you can find bugs in what I've already done > -without- an LLM - you will learn the code at the same time, and > then be in a much better place to guide an LLM through later stages > of development. > > Cheers, > > Dave. > Thanks for posting the WIP series. I’ll work from the log-verification-1 branch and first study the generic iterator and item handling rather than extending the old special cases. I’ll pay particular attention to arbitrary continuation fragments, zero-length first fragments, transaction-header completion, and cleanup on malformed input. I’ll review the existing code for bugs before adding the per-item validation functions, and will point you to my repository once I have work based on the branch. Thanks, Hongling