> On Jun 15, 2023, at 3:14 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > > On Thu, Jun 15, 2023 at 09:57:18PM +0000, Wengang Wang wrote: >> Hi Dave, >> >> I got this error when applying this patch to the newest code: >> (I tried on both MacOS and OL8, it’s the same result) >> >> $ patch -p1 <~/tmp/Dave1.txt >> patching file 'fs/xfs/libxfs/xfs_alloc.c' >> patch: **** malformed patch at line 27: */ > > Whoa. I haven't use patch like this for a decade. :) > > The way all the cool kids do this now is apply the entire series to > directly to a git tree branch with b4: > > $ b4 am -o - 20230615014201.3171380-2-david@xxxxxxxxxxxxx | git am > > (b4 shazam merges the b4 am and git am operations into the one > command, IIRC, but that trick isn't automatic for me yet :) >> Looking at the patch to see the line numbers: >> >> 22 diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c >> 23 index c20fe99405d8..11bd0a1756a1 100644 >> 24 --- a/fs/xfs/libxfs/xfs_alloc.c >> 25 +++ b/fs/xfs/libxfs/xfs_alloc.c >> 26 @@ -1536,7 +1536,8 @@ xfs_alloc_ag_vextent_lastblock( >> 27 */ >> 28 STATIC int >> 29 xfs_alloc_ag_vextent_near( > > Yup, however you saved the patch to a file stripped the leading > spaces from all the lines in the patch. > > If you look at the raw email on lore it has the correct leading > spaces in the patch. > > https://lore.kernel.org/linux-xfs/20230615014201.3171380-2-david@xxxxxxxxxxxxx/raw > > These sorts of patching problems go away when you use tools like b4 > to pull the patches directly from the mailing list... > >>> On Jun 14, 2023, at 6:41 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >>> >>> From: Dave Chinner <dchinner@xxxxxxxxxx> >>> >>> To avoid blocking in xfs_extent_busy_flush() when freeing extents >>> and the only busy extents are held by the current transaction, we >>> need to pass the XFS_ALLOC_FLAG_FREEING flag context all the way >>> into xfs_extent_busy_flush(). >>> >>> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx> >>> --- >>> fs/xfs/libxfs/xfs_alloc.c | 96 +++++++++++++++++++++------------------ >>> fs/xfs/libxfs/xfs_alloc.h | 2 +- >>> fs/xfs/xfs_extent_busy.c | 3 +- >>> fs/xfs/xfs_extent_busy.h | 2 +- >>> 4 files changed, 56 insertions(+), 47 deletions(-) >>> >>> diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c >>> index c20fe99405d8..11bd0a1756a1 100644 >>> --- a/fs/xfs/libxfs/xfs_alloc.c >>> +++ b/fs/xfs/libxfs/xfs_alloc.c >>> @@ -1536,7 +1536,8 @@ xfs_alloc_ag_vextent_lastblock( >>> */ >>> STATIC int >>> xfs_alloc_ag_vextent_near( >>> - struct xfs_alloc_arg *args) >>> + struct xfs_alloc_arg *args, >>> + uint32_t alloc_flags) >>> { >>> struct xfs_alloc_cur acur = {}; >>> int error; /* error code */ > > This indicates the problem is likely to be your mail program, > because the quoting it has done here has completely mangled all the > whitespace in the patch.... > Right, the .txt was not raw. Now I got the raw formats and they applied to upstream master. Let me run log recover with my metadump, will report result later. thanks, wengang > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
