[CRIU] [PATCH 1/4] check: seccomp suspend is now in mainline

[Kir Kolyshkin]

On 10/19/2015 09:46 AM, Tycho Andersen wrote:
> On Mon, Oct 19, 2015 at 09:37:42AM -0700, Kir Kolyshkin wrote:
>>
>> On 10/19/2015 07:25 AM, Tycho Andersen wrote:
>>> Hi Kir,
>>>
>>> On Sun, Oct 18, 2015 at 02:30:13PM -0700, Kir Kolyshkin wrote:
>>>> On 10/15/2015 03:28 PM, Tycho Andersen wrote:
>>>>> As of
>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=13c4a9011
>>>>> PTRACE_O_SUSPEND_SECCOMP is in the mainline kernel, so we should check for
>>>>> it in --ms.
>>>> Well, it was actually only merged in
>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=b793c00
>>>> so the first kernel it's included is v4.3-rc1. As 4.3 is not yet released,
>>>> I'd say hold this patch for a few months.
>>>>
>>>> In the mean time, I found out a horrible horrible thing -- apparently we
>>>> can't
>>>> rely on "git describe --tags" to tell us when a patch was included. For
>>>> example,
>>>> this patch adding PTRACE_O_SUSPEND_SECCOMP is commit 13c4a90, and
>>>>
>>>> [kir at kir-tpad linux]$ git describe --tags 13c4a901
>>>> v4.1-rc1-43-g13c4a90
>>>>
>>>> I guess this is the reason why https://criu.org/Upstream_kernel_commits
>>>> [incorrectly] lists (listed -- I just fixed it) it to be included into
>>>> 4.1-rc2.
>>>> In fact, it was only included into v4.3-rc1, as shown above.
>>>>
>>>> This is because git describe looks back in history from the given commit
>>>> to the previous, i.e. earlier tag. In order to make sure since when the
>>>> patch
>>>> is included, we need to look the other direction. The problem, of course, is
>>>> there is no single way.
>>> Interesting that it still gave 4.1 instead of something in 4.3-rc.
>> Do you mean wiki or git describe?
> git describe,
>
>> Wiki looks good to me, and for git describe you need to use --contains
>> option as explained below.
> contains looks forward, but describe looks backwards. Surely there was
> a tag in between the 4.1 tag and the 4.3-rc? I don't see why git
> describe doesn't report e.g. 4.2 or something instead.

My understanding is a branch to which this patch was committed was based
on 4.1-rc1 and apparently was never rebased onto something newer.

Next step, Linus merged it to his tree after 4.3, but a merge is not a 
rebase
and so this patch still has 4.1-rc1 as its grandparent.