On Sun, May 22, 2022 at 10:01 PM Damien Le Moal
<damien.lemoal@xxxxxxxxxxxxxxxxxx> wrote:
>
> Note: I made a mistake during this PR preparation and inadvertantly deleted the
> for-5.19 branch used for this PR. I recreated it and prepared the PR using this
> newly pushed for-5.19 branch. All patches have been in linux-next for a while.
> I hope this does not trigger any problem on your end.
Grr.
That seems to be the cause of repeated commits, which in turn then
caused conflicts because you had further changes.
IOW, I already had gotten
zonefs: Fix management of open zones
zonefs: Clear inode information flags on inode creation
from the block tree (your commits), and your branch now had different
copies of those commits.
And you don't actually list those commits, which makes me think that
you then did some manual editing of the pull request.
The duplicate commits with identical contents then caused commit
87c9ce3ffec9 ("zonefs: Add active seq file accounting") to show as a
conflict, because the different branches did *some* things the same,
but then that commit added other changes.
And honestly, I think that commit is buggy.
In particular, notice how the locking changes in that commit means
that zonefs_init_file_inode() now always returns 0, even if
zonefs_zone_mgmt() failed with an error.
The error cause it to skip "zonefs_account_active()", but then it
returns success anyway.
Was that really intentional?
I've merged this - with that apparent bug and all - because maybe it
*was* intentional. But please double-check and confirm that you really
intended zonefs_init_file_inode() to always return success, unlike the
old behavior.
Linus
