From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6542CC4332F for ; Mon, 12 Dec 2022 23:19:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230052AbiLLXTG (ORCPT ); Mon, 12 Dec 2022 18:19:06 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39128 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229670AbiLLXTE (ORCPT ); Mon, 12 Dec 2022 18:19:04 -0500 Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 250DD12D2F for ; Mon, 12 Dec 2022 15:19:03 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id h6so852457iof.9 for ; Mon, 12 Dec 2022 15:19:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=WkpQCN5mKfNvNkgy40wCy1sH1Bpo4in6NPsoEBjZknc=; b=MtQwofhI4jKH8Ram4EX0F52D5bPmzKC4aoYpXmHoc5HFc3ZZkDITGfBo1fBRN6rEWz 8l92iMnWF7CpIUhgQGFvCOVKTa+6DXFVaNGROEtZ9mQtF6FFzy4pHhV+x6UXuOPdn3Mi hAOxofQqoCKZD3o4bAJnLx68qb8sc08xdxzi8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WkpQCN5mKfNvNkgy40wCy1sH1Bpo4in6NPsoEBjZknc=; b=YE39YO3XbNdkZ0Cmmg773m5miqDVLhJoIACaEHRk7cJJZGEEifE2hxqxxdVfSPwu+e 2DvHTJQCwR/750RcUu+nFSCJlDQ2+TV132hniUOf1MDLkcHzkQgW9pGnwaLo270te+AR FsfGpjw9x/7PbkQx1tLYQtaKRuNzpDuFP5rScIWxEk4JUQZnC9MWxvR/rPBYO8MOP40A giiyz2w8OFXiY20gvy+AEGVSlDVw77WKaw1O/WF1R5TwwQPgg6Cl+WmKyChHO0yLl6Vi Z6r3jyrSbYiJ+6iMC0q7jto5+ro7jVJUr7fGEKRoIqKBubWnQXPe2lNbHzHtYXEsMoYu /riw== X-Gm-Message-State: ANoB5pnT9RZc0nEdfj+EUrXSibMioGZy5nMbyZeZB1TnNzhfe9BbmUBj lRbCDQvOJrzM99SyAMSIqyCY1A== X-Google-Smtp-Source: AA0mqf4Ppkd+xCnV95v8ipzZ4L9ywn/vFPptElVZl80pZntWElatvsr9RMj/4Dx+zjpqDTi1o3WWuw== X-Received: by 2002:a6b:4916:0:b0:6dd:7096:d9bc with SMTP id u22-20020a6b4916000000b006dd7096d9bcmr1898863iob.2.1670887142377; Mon, 12 Dec 2022 15:19:02 -0800 (PST) Received: from [192.168.1.128] ([38.15.45.1]) by smtp.gmail.com with ESMTPSA id m19-20020a026a53000000b0038a5b8d79basm336764jaf.106.2022.12.12.15.19.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Dec 2022 15:19:01 -0800 (PST) Message-ID: Date: Mon, 12 Dec 2022 16:19:00 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: linux-next: manual merge of the kunit-next tree with the apparmor tree Content-Language: en-US To: John Johansen , Stephen Rothwell , Brendan Higgins , David Gow Cc: Linux Kernel Mailing List , Linux Next Mailing List , Rae Moar , Shuah Khan References: <20221208135327.01364529@canb.auug.org.au> <8e82905f-8bdf-05de-2e6a-d8b896d75910@linuxfoundation.org> <0e678eb2-455c-88f5-6732-2e8701ebb6e6@linuxfoundation.org> <9b21c055-4e1a-2c34-281c-39af7d73fe80@canonical.com> From: Shuah Khan In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-next@vger.kernel.org On 12/12/22 12:53, John Johansen wrote: > On 12/12/22 11:48, Shuah Khan wrote: >> 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 >> > > okay > >>> 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. >> > > ack > >>> 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. >> > > yeah, my bad > No worries. Sent pull request with a note about apparmor and our coordinated pull requests with you on the cc. thanks, -- Shuah