Re: [PATCH 1/3] xfs: pass alloc flags through to xfs_extent_busy_flush()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> 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






[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux