Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1407893 > unrolled thread

Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes Laurent Dufour <ldufour@linux.vnet.ibm.com> - 2016-05-27 10:10 +0200
    Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes Michael Ellerman <mpe@ellerman.id.au> - 2016-05-31 01:20 +0200
      Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2016-06-01 10:30 +0200
      Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes Anshuman Khandual <khandual@linux.vnet.ibm.com> - 2016-06-06 11:00 +0200
        Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes Michael Ellerman <mpe@ellerman.id.au> - 2016-06-08 13:20 +0200

#1407893 — Re: [PATCH V10 00/28] Add new powerpc specific ELF core notes

On 21/04/2016 18:00, Laurent Dufour wrote:
> On 13/04/2016 07:14, Michael Ellerman wrote:
>> On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote:
>>> On 07/04/2016 23:49, Michael Ellerman wrote:
>>>> On 7 April 2016 7:23:46 pm AEST, Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote:
>>>>> This series is required to handle TM state in CRIU.
>>>>> Is there a chance to get it upstream soon ?
>>>>
>>>> We were waiting on the gdb support to make sure it had some testing. If it's working for CRIU that would be a good data point, have you actually tested it with CRIU?
>>>
>>> I just started integrating it in CRIU, my basic tests didn't report any
>>> issue with the new ptrace API, but I can't state that it is bug free ;)
>>
>> Sure. But if it's working for CRIU that's at least postive :)
> 
> I did additional tests and the Anshuman's series is working fine for
> CRIU's support with the attached patch applied.
> 
> Michael, could you please applied the attached patch among the
> Anshuman's series ?

Hi Michael,

Is there any chance we get this series pushed in 4.7 ?

Thanks,
Laurent.

[toc] | [next] | [standalone]

#1409750

On Fri, 2016-05-27 at 10:07 +0200, Laurent Dufour wrote:

> On 21/04/2016 18:00, Laurent Dufour wrote:

> > On 13/04/2016 07:14, Michael Ellerman wrote:

> > > On Mon, 2016-04-11 at 09:40 +0200, Laurent Dufour wrote:

> > > > On 07/04/2016 23:49, Michael Ellerman wrote:

> > > > > On 7 April 2016 7:23:46 pm AEST, Laurent Dufour <ldufour@linux.vnet.ibm.com> wrote:

> > > > > > This series is required to handle TM state in CRIU.
> > > > > > Is there a chance to get it upstream soon ?
> > > > > 
> > > > > We were waiting on the gdb support to make sure it had some testing. If it's working for CRIU that would be a good data point, have you actually tested it with CRIU?
> > > > 
> > > > I just started integrating it in CRIU, my basic tests didn't report any
> > > > issue with the new ptrace API, but I can't state that it is bug free ;)
> > > 
> > > Sure. But if it's working for CRIU that's at least postive :)
> > 
> > I did additional tests and the Anshuman's series is working fine for
> > CRIU's support with the attached patch applied.
> > 
> > Michael, could you please applied the attached patch among the
> > Anshuman's series ?
> 
> Hi Michael,
> 
> Is there any chance we get this series pushed in 4.7 ?

Hi Laurent,

Sorry no. My next branch closed for 4.7 about 3 weeks ago.

This series has been blocked for a long time on the gdb support, but that is
now working. However it still doesn't pass its own selftests, and I had some
disagreements with the implementation - it duplicates a lot of code rather
than refactoring things.

I'm waiting on a patch from Cyril which will rework how the TM FP state is
handled, and that should make this series easier to implement.

The plan is that both should go into 4.8.

cheers

[toc] | [prev] | [next] | [standalone]

#1410935

On 05/31/2016 04:42 AM, Michael Ellerman wrote:
> Hi Laurent,
> 
> Sorry no. My next branch closed for 4.7 about 3 weeks ago.
> 
> This series has been blocked for a long time on the gdb support, but that is
> now working. However it still doesn't pass its own selftests, and I had some

This series was clearing all of the selftests at the time it was posted.
But yes, it has some assumptions from timing and sync perspective which
gets broken some times as the kernel changes. Its been bit difficult to
perfect the sync requirements as we can do only some much inside the
transaction once it gets started. There are scopes here to improve these
selftests but not clearing them today does not really mean the patches are
now functionally broken.

> disagreements with the implementation - it duplicates a lot of code rather
> than refactoring things.

hmm, sorry, I dont remember the context here. Can you please point to the
discussion in this regard ?

> 
> I'm waiting on a patch from Cyril which will rework how the TM FP state is
> handled, and that should make this series easier to implement.

Can you please elaborate on this ? Has this patch been posted in the mailing
list ? How does this make it easier for us to implement these ELF notes ?

> 
> The plan is that both should go into 4.8.

[toc] | [prev] | [next] | [standalone]

#1414798

On 06/03/2016 03:56 AM, Cyril Bur wrote:
> On 1 June 2016 at 18:26, Anshuman Khandual <khandual@linux.vnet.ibm.com>
> wrote:
> 
>> On 05/31/2016 04:42 AM, Michael Ellerman wrote:
>>> Hi Laurent,
>>>
>>> Sorry no. My next branch closed for 4.7 about 3 weeks ago.
>>>
>>> This series has been blocked for a long time on the gdb support, but
>> that is
>>> now working. However it still doesn't pass its own selftests, and I had
>> some
>>
>> This series was clearing all of the selftests at the time it was posted.
>> But yes, it has some assumptions from timing and sync perspective which
>> gets broken some times as the kernel changes. Its been bit difficult to
>> perfect the sync requirements as we can do only some much inside the
>> transaction once it gets started. There are scopes here to improve these
>> selftests but not clearing them today does not really mean the patches are
>> now functionally broken.
>>
>>> disagreements with the implementation - it duplicates a lot of code
>> rather
>>> than refactoring things.
>>
>> hmm, sorry, I dont remember the context here. Can you please point to the
>> discussion in this regard ?
>>
>>>
>>> I'm waiting on a patch from Cyril which will rework how the TM FP state
>> is
>>> handled, and that should make this series easier to implement.
>>
>> Can you please elaborate on this ? Has this patch been posted in the
>> mailing
>> list ? How does this make it easier for us to implement these ELF notes ?
> 
> 
> Hi Anshuman,
> 
> I'm doing a bit of a rewrite of the TM handling of the FP/VMX/VSX state.
> 
> At the moment is is rather confusing since pt_regs is the always the 'live'
> state
> and theres a ckpt_regs that is the pt_regs for the checkpointed state.
> FPU/VMX/VSX
> is done differently which is really only creating confusion so I'm changing
> it to do the
> same at for pt_regs/ckpt_regs. Ultimately this is part of more work from me

But that changes the basic semantics on which this ptrace series is written.
With this change, a significant part of the ptrace series has to be changed.
Its just an improvement on how we store running and check pointed values for
FP/VSX/VMX registers inside the kernel. How does it improve ptrace interface
from the user point of view ? If not, then why this change is necessary for
the acceptance of this patch series ? This change should be implemented as
an independent work and then necessary ptrace change can be incorporated
there after.

> but
> Michael has told me that at least this bit is useful now so I'm splitting
> it off from
> the bigger picture and sending asap. At the very least it will make it
> easier to know
> what and where the transactional state it and where the checkpointed state
> is.
> 
> It isn't on the list but I hope I'll get it out today.

[toc] | [prev] | [next] | [standalone]

#1417300

On Mon, 2016-06-06 at 14:27 +0530, Anshuman Khandual wrote:
> On 06/03/2016 03:56 AM, Cyril Bur wrote:
> > 
> > At the moment is is rather confusing since pt_regs is the always the 'live'
> > state and theres a ckpt_regs that is the pt_regs for the checkpointed state.
> > FPU/VMX/VSX is done differently which is really only creating confusion so I'm changing
> > it to do the same at for pt_regs/ckpt_regs. Ultimately this is part of more work from me
> 
> But that changes the basic semantics on which this ptrace series is written.
> With this change, a significant part of the ptrace series has to be changed.

Yes, that's the whole point.

In fact half of the code should vanish, because the only difference between
copying the live or checkpointed state out to userspace should be which regs
struct you pass to the function.

> Its just an improvement on how we store running and check pointed values for
> FP/VSX/VMX registers inside the kernel. How does it improve ptrace interface
> from the user point of view ? If not, then why this change is necessary for
> the acceptance of this patch series ?

Because the clean-ups never happen once a series is merged, and I'm left to deal
with it.

cheers

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web