On 12/12/22 12:20, John Johansen wrote:
On 12/12/22 10:03, Shuah Khan wrote:
On 12/12/22 10:52, Shuah Khan wrote:
Hi David,
On 12/8/22 13:10, John Johansen wrote:
On 12/7/22 18:53, Stephen Rothwell wrote:
Hi all,
Today's linux-next merge of the kunit-next tree got a conflict in:
security/apparmor/policy_unpack.c
between commits:
371e50a0b19f ("apparmor: make unpack_array return a trianary value")
73c7e91c8bc9 ("apparmor: Remove unnecessary size check when unpacking trans_table")
217af7e2f4de ("apparmor: refactor profile rules and attachments")
(and probably others)
from the apparmor tree and commit:
2c92044683f5 ("apparmor: test: make static symbols visible during kunit testing")
from the kunit-next tree.
This is somewhat of a mess ... pity there is not a shared branch (or
better routing if the patches).
sorry, there was a miscommunication/misunderstanding, probably all on me, I
thought the kunit stuff that is conflicting here was going to merge next
cycle.
How about I just drop the following for now and handle this in the next cycle?
if you want, the other way to handle it is we coordinate our pull requests.
You go first. And then I will submit a little later in the week, with the
references to the merge conflict and a pointer to a branch with it resolved.
This isn't even a particularly tricky merge conflict, it just has the little
subtly around making sure the include symbols are conditional.
I assume Linus will not see any problems without your pull requests. In which
case we can do this:
- I send my pull request today
- You can follow with yours with the fixes later on this week
This doesn't affect me much as there is already another merge conflict with
the security tree that I need to deal with.
I think it might be least confusing option. Let me know. I can just do that
and then send pull request in a day or tow once things settle down in next.
2c92044683f5 ("apparmor: test: make static symbols visible during kunit testing")
that is the other option. If you go that route I can help you do the rebase/merge
fix.
Let's go with your earlier suggestion.
looking back at this, there wasn't anything explicit about this not going upstream
this cycle, I must have just assumed as the final version came about after rc7. So
my bad.
Right - I ended up taking this as it looked like a patch if included could
enable other changes to follow without being blocked. Also rc8 was in plan.
thanks,
-- Shuah
