Patchwork [GIT,PULL] ARM: kprobes: big-endian support

login
register
mail settings
Submitter Taras Kondratiuk
Date Jan. 13, 2014, 12:09 p.m.
Message ID <52D3D784.2000600@linaro.org>
Download mbox
Permalink /patch/309811/
State New
Headers show

Pull-request

git://git.linaro.org/people/taras.kondratiuk/linux.git tags/for_russell/arm-be-kprobes

Comments

Taras Kondratiuk - Jan. 13, 2014, 12:09 p.m.
Hi Russell,

Please pull fixes for ARM Kprobes big-endian support.

It is reworked initial Ben's series for big endian support [1].
Dropped patches that are not directly related to kprobes.
Current set of patches is enough to have functional BE kprobes.

One ARM kprobe test fails on Cortex-A15 boards (TC2 and Keystone2 EVM),
while it passes on Pandaboard. The issue is not related to this series
and already present in v3.13-rc7.

[1] http://www.spinics.net/lists/arm-kernel/msg285210.html
Taras Kondratiuk - Feb. 19, 2014, 10:59 p.m.
On 01/13/2014 02:09 PM, Taras Kondratiuk wrote:
> Hi Russell,
> 
> Please pull fixes for ARM Kprobes big-endian support.
> 
> It is reworked initial Ben's series for big endian support [1].
> Dropped patches that are not directly related to kprobes.
> Current set of patches is enough to have functional BE kprobes.
> 
> One ARM kprobe test fails on Cortex-A15 boards (TC2 and Keystone2 EVM),
> while it passes on Pandaboard. The issue is not related to this series
> and already present in v3.13-rc7.
> 
> [1] http://www.spinics.net/lists/arm-kernel/msg285210.html
> 

Hi Russell,

This pull request is based on 3.13-rc8, but it applies cleanly to
3.14-rc3, because kprobes are not touched since then.
Do I need to resent a new pull request based on 3.14-rc3 anyway?
Taras Kondratiuk - March 26, 2014, 10:26 a.m.
On 02/20/2014 12:59 AM, Taras Kondratiuk wrote:
> On 01/13/2014 02:09 PM, Taras Kondratiuk wrote:
>> Hi Russell,
>>
>> Please pull fixes for ARM Kprobes big-endian support.
>>
>> It is reworked initial Ben's series for big endian support [1].
>> Dropped patches that are not directly related to kprobes.
>> Current set of patches is enough to have functional BE kprobes.
>>
>> One ARM kprobe test fails on Cortex-A15 boards (TC2 and Keystone2 EVM),
>> while it passes on Pandaboard. The issue is not related to this series
>> and already present in v3.13-rc7.
>>
>> [1] http://www.spinics.net/lists/arm-kernel/msg285210.html
>>
> 
> Hi Russell,
> 
> This pull request is based on 3.13-rc8, but it applies cleanly to
> 3.14-rc3, because kprobes are not touched since then.
> Do I need to resent a new pull request based on 3.14-rc3 anyway?
> 

Hi Russell,

Is there any issue with this pull request?
Should I do something to get it pulled?
Russell King - ARM Linux - March 28, 2014, 11:28 a.m.
On Wed, Mar 26, 2014 at 12:26:34PM +0200, Taras Kondratiuk wrote:
> On 02/20/2014 12:59 AM, Taras Kondratiuk wrote:
> > On 01/13/2014 02:09 PM, Taras Kondratiuk wrote:
> >> Hi Russell,
> >>
> >> Please pull fixes for ARM Kprobes big-endian support.
> >>
> >> It is reworked initial Ben's series for big endian support [1].
> >> Dropped patches that are not directly related to kprobes.
> >> Current set of patches is enough to have functional BE kprobes.
> >>
> >> One ARM kprobe test fails on Cortex-A15 boards (TC2 and Keystone2 EVM),
> >> while it passes on Pandaboard. The issue is not related to this series
> >> and already present in v3.13-rc7.
> >>
> >> [1] http://www.spinics.net/lists/arm-kernel/msg285210.html
> >>
> > 
> > Hi Russell,
> > 
> > This pull request is based on 3.13-rc8, but it applies cleanly to
> > 3.14-rc3, because kprobes are not touched since then.
> > Do I need to resent a new pull request based on 3.14-rc3 anyway?
> > 
> 
> Hi Russell,
> 
> Is there any issue with this pull request?
> Should I do something to get it pulled?

There's nothing wrong, apart from me being far too busy hacking on really
crap code to care about reading much email - which means that lots of
email simply just gets buried and lost.

There is now a problem with this pull - it conflicts very badly with Dave
Long's uprobes code, which I've already pulled, so much so that I'm not
happy to do the conflict resolution since I know nothing about this code,
and it's a feature I don't make any use of.

I notice that Dave Long and yourself are both under the Linaro umbrella,
but there seems to be no coordination between yourselves, despite working
on the same code...
Taras Kondratiuk - March 28, 2014, 6:13 p.m.
On 03/28/2014 01:28 PM, Russell King - ARM Linux wrote:
> On Wed, Mar 26, 2014 at 12:26:34PM +0200, Taras Kondratiuk wrote:
>> On 02/20/2014 12:59 AM, Taras Kondratiuk wrote:
>>
>> Hi Russell,
>>
>> Is there any issue with this pull request?
>> Should I do something to get it pulled?
> 
> There's nothing wrong, apart from me being far too busy hacking on really
> crap code to care about reading much email - which means that lots of
> email simply just gets buried and lost.
> 
> There is now a problem with this pull - it conflicts very badly with Dave
> Long's uprobes code, which I've already pulled, so much so that I'm not
> happy to do the conflict resolution since I know nothing about this code,
> and it's a feature I don't make any use of.

I've rebased it onto your for-next branch. Kprobes are functional
in LE and BE. I'll send an updated pull request after verifying uprobes.

> I notice that Dave Long and yourself are both under the Linaro umbrella,
> but there seems to be no coordination between yourselves, despite working
> on the same code...

Yeah, we are working in different teams and unfortunately haven't coordinated
an upstreaming sequence.
Russell King - ARM Linux - March 28, 2014, 6:22 p.m.
On Fri, Mar 28, 2014 at 08:13:05PM +0200, Taras Kondratiuk wrote:
> On 03/28/2014 01:28 PM, Russell King - ARM Linux wrote:
> > On Wed, Mar 26, 2014 at 12:26:34PM +0200, Taras Kondratiuk wrote:
> >> On 02/20/2014 12:59 AM, Taras Kondratiuk wrote:
> >>
> >> Hi Russell,
> >>
> >> Is there any issue with this pull request?
> >> Should I do something to get it pulled?
> > 
> > There's nothing wrong, apart from me being far too busy hacking on really
> > crap code to care about reading much email - which means that lots of
> > email simply just gets buried and lost.
> > 
> > There is now a problem with this pull - it conflicts very badly with Dave
> > Long's uprobes code, which I've already pulled, so much so that I'm not
> > happy to do the conflict resolution since I know nothing about this code,
> > and it's a feature I don't make any use of.
> 
> I've rebased it onto your for-next branch. Kprobes are functional
> in LE and BE. I'll send an updated pull request after verifying uprobes.

That's not going to work.  for-next is an unstable branch - all the
merge commits there get regenerated on a fairly regular basis.

A better solution would be to base your patches on top of Dave Long's
changes, which can be found at

 git://git.linaro.org/people/dave.long/linux uprobes-v7

and should have an ID of c7edc9e326d5.
Taras Kondratiuk - March 28, 2014, 9:43 p.m.
On 03/28/2014 08:22 PM, Russell King - ARM Linux wrote:
> On Fri, Mar 28, 2014 at 08:13:05PM +0200, Taras Kondratiuk wrote:
>> On 03/28/2014 01:28 PM, Russell King - ARM Linux wrote:
>>> On Wed, Mar 26, 2014 at 12:26:34PM +0200, Taras Kondratiuk wrote:
>>>> On 02/20/2014 12:59 AM, Taras Kondratiuk wrote:
>>>>
>>>> Hi Russell,
>>>>
>>>> Is there any issue with this pull request?
>>>> Should I do something to get it pulled?
>>>
>>> There's nothing wrong, apart from me being far too busy hacking on really
>>> crap code to care about reading much email - which means that lots of
>>> email simply just gets buried and lost.
>>>
>>> There is now a problem with this pull - it conflicts very badly with Dave
>>> Long's uprobes code, which I've already pulled, so much so that I'm not
>>> happy to do the conflict resolution since I know nothing about this code,
>>> and it's a feature I don't make any use of.
>>
>> I've rebased it onto your for-next branch. Kprobes are functional
>> in LE and BE. I'll send an updated pull request after verifying uprobes.
> 
> That's not going to work.  for-next is an unstable branch - all the
> merge commits there get regenerated on a fairly regular basis.
> 
> A better solution would be to base your patches on top of Dave Long's
> changes, which can be found at
> 
>  git://git.linaro.org/people/dave.long/linux uprobes-v7
> 
> and should have an ID of c7edc9e326d5.

Ok I'll base on Dave's branch.