[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Geert Uytterhoeven]

If CONFIG_DEBUG_LOCK_ALLOC=y, the kernel log is spammed with a few
hundred identical messages:

    unwind: Unknown symbol address c0800300
    unwind: Index not found c0800300

c0800300 is the return address from the last subroutine call (to
__memzero()) in __mmap_switched().  Apparently having this address in
the link register confuses the unwinder.

To fix this, reset the link register to zero before jumping to
start_kernel().

Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Commit 9520b1a1b5f7a348 is in arm/for-next.

 arch/arm/kernel/head-common.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
index a25027b87a6024b9..21dde771a7dd8d14 100644
--- a/arch/arm/kernel/head-common.S
+++ b/arch/arm/kernel/head-common.S
@@ -114,6 +114,7 @@ __mmap_switched:
 	str	r8, [r2]			@ Save atags pointer
 	cmp	r3, #0
 	strne	r10, [r3]			@ Save control register values
+	mov	lr, #0
 	b	start_kernel
 ENDPROC(__mmap_switched)
 
-- 
2.7.4

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Nicolas Pitre]

On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:

> If CONFIG_DEBUG_LOCK_ALLOC=y, the kernel log is spammed with a few
> hundred identical messages:
> 
>     unwind: Unknown symbol address c0800300
>     unwind: Index not found c0800300
> 
> c0800300 is the return address from the last subroutine call (to
> __memzero()) in __mmap_switched().  Apparently having this address in
> the link register confuses the unwinder.
> 
> To fix this, reset the link register to zero before jumping to
> start_kernel().
> 
> Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
> Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>

Good! This fixes another similar case I had but I didn't come around to 
look at closely yet.

Acked-by: Nicolas Pitre <nico@linaro.org>

Please send it to RMK's patch system.


> ---
> Commit 9520b1a1b5f7a348 is in arm/for-next.
> 
>  arch/arm/kernel/head-common.S | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/arch/arm/kernel/head-common.S b/arch/arm/kernel/head-common.S
> index a25027b87a6024b9..21dde771a7dd8d14 100644
> --- a/arch/arm/kernel/head-common.S
> +++ b/arch/arm/kernel/head-common.S
> @@ -114,6 +114,7 @@ __mmap_switched:
>  	str	r8, [r2]			@ Save atags pointer
>  	cmp	r3, #0
>  	strne	r10, [r3]			@ Save control register values
> +	mov	lr, #0
>  	b	start_kernel
>  ENDPROC(__mmap_switched)
>  
> -- 
> 2.7.4
> 
> 

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Geert Uytterhoeven]

On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>
>> If CONFIG_DEBUG_LOCK_ALLOC=y, the kernel log is spammed with a few
>> hundred identical messages:
>>
>>     unwind: Unknown symbol address c0800300
>>     unwind: Index not found c0800300
>>
>> c0800300 is the return address from the last subroutine call (to
>> __memzero()) in __mmap_switched().  Apparently having this address in
>> the link register confuses the unwinder.
>>
>> To fix this, reset the link register to zero before jumping to
>> start_kernel().
>>
>> Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")
>> Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> Good! This fixes another similar case I had but I didn't come around to
> look at closely yet.
>
> Acked-by: Nicolas Pitre <nico@linaro.org>

Thanks!

> Please send it to RMK's patch system.

Done (I hope so ;-)

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Geert Uytterhoeven]

On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>> Please send it to RMK's patch system.
>
> Done (I hope so ;-)

Failed. Retrying.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Geert Uytterhoeven]

On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>>> Please send it to RMK's patch system.
>>
>> Done (I hope so ;-)
>
> Failed. Retrying.

Yiha ;-)

http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Tony Lindgren]

* Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
> On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
> >>> Please send it to RMK's patch system.
> >>
> >> Done (I hope so ;-)
> >
> > Failed. Retrying.
> 
> Yiha ;-)
> 
> http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1

This also fixes the spamming I started seeing with next-20171009:

Tested-by: Tony Lindgren <tony@atomide.com>

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Russell King - ARM Linux]

On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
> * Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
> > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
> > >>> Please send it to RMK's patch system.
> > >>
> > >> Done (I hope so ;-)
> > >
> > > Failed. Retrying.
> > 
> > Yiha ;-)
> > 
> > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
> 
> This also fixes the spamming I started seeing with next-20171009:
> 
> Tested-by: Tony Lindgren <tony@atomide.com>

It's all nice and good that people are testing this patch, but I can't
apply it to -rc1, nor my "misc" branch.  It appears that this is due
to patches going through other trees.

Sorry, I can't take this patch.

(This is the falicy about any one particular tree having rights to
exclusively own a sub-tree in the kernel...)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Geert Uytterhoeven]

Hi Russell, Nicolas,

On Thu, Oct 12, 2017 at 12:23 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
>> * Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
>> > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>> > >>> Please send it to RMK's patch system.
>> > >>
>> > >> Done (I hope so ;-)
>> > >
>> > > Failed. Retrying.
>> >
>> > Yiha ;-)
>> >
>> > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
>>
>> This also fixes the spamming I started seeing with next-20171009:
>>
>> Tested-by: Tony Lindgren <tony@atomide.com>
>
> It's all nice and good that people are testing this patch, but I can't
> apply it to -rc1, nor my "misc" branch.  It appears that this is due
> to patches going through other trees.
>
> Sorry, I can't take this patch.
>
> (This is the falicy about any one particular tree having rights to
> exclusively own a sub-tree in the kernel...)

So through which tree did this end up in -next?

Apparently Nicolas committed 9520b1a1b5f7a348 ("ARM: head-common.S: speed up
startup code") himself, and then asked me to send the fix for that commit to
Russell anyway?
The commit above is actually in Russell's
git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next.

Russell, you did merge it yourself into for-next in commit 476242482bdee72b
("Merge branch 'xip_zdata' of http://git.linaro.org/people/nicolas.pitre/linux
into devel-testing").

My patch applies fine against your for-next branch. So I fail to see why
you can't take this patch?

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Nicolas Pitre]

On Thu, 12 Oct 2017, Russell King - ARM Linux wrote:

> On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
> > * Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
> > > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
> > > >>> Please send it to RMK's patch system.
> > > >>
> > > >> Done (I hope so ;-)
> > > >
> > > > Failed. Retrying.
> > > 
> > > Yiha ;-)
> > > 
> > > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
> > 
> > This also fixes the spamming I started seeing with next-20171009:
> > 
> > Tested-by: Tony Lindgren <tony@atomide.com>
> 
> It's all nice and good that people are testing this patch, but I can't
> apply it to -rc1, nor my "misc" branch.  It appears that this is due
> to patches going through other trees.
> 
> Sorry, I can't take this patch.

It should go into your devel-testing branch as this must be applied on 
top of my xip_zdata branch that you merged there.


Nicolas

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Russell King - ARM Linux]

On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> On Thu, 12 Oct 2017, Russell King - ARM Linux wrote:
> 
> > On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
> > > * Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
> > > > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > > > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
> > > > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
> > > > >>> Please send it to RMK's patch system.
> > > > >>
> > > > >> Done (I hope so ;-)
> > > > >
> > > > > Failed. Retrying.
> > > > 
> > > > Yiha ;-)
> > > > 
> > > > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
> > > 
> > > This also fixes the spamming I started seeing with next-20171009:
> > > 
> > > Tested-by: Tony Lindgren <tony@atomide.com>
> > 
> > It's all nice and good that people are testing this patch, but I can't
> > apply it to -rc1, nor my "misc" branch.  It appears that this is due
> > to patches going through other trees.
> > 
> > Sorry, I can't take this patch.
> 
> It should go into your devel-testing branch as this must be applied on 
> top of my xip_zdata branch that you merged there.

Thanks, it would've been good to have known that ahead of time.

It's why the patch system has the KernelVersion: tag:

?6.?Kernel version.
    On a separate line, add a tag "KernelVersion: " followed by the kernel
    version that the patch was generated against. This should be formatted
    as "KernelVersion: 2.6.0-rmk1"

This is because that information is relevant for knowing where it should
be applied, and to which branch.  Having it be something else means I
have to guess, and that can result in the patch being discarded in this
manner if I don't find where it's supposed to be applied.

Yes, I know it's a pain to have to supply this information, but giving
accurate information there makes things a lot easier and quicker when
applying patches, rather than playing a game of "guess where it needs
to be applied, nope, doesn't apply there, try somewhere else."

Various people in the kernel community have different solutions to this.
For example, on netdev, it is preferred to state whether you want your
patch to be applied to "net" or "net-next" by adding that into the
"[PATCH ...]" tag in the subject line.  It's really about streamlining
the patch submission and application process.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Russell King - ARM Linux]

On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > It should go into your devel-testing branch as this must be applied on 
> > top of my xip_zdata branch that you merged there.
> 
> Thanks, it would've been good to have known that ahead of time.
> 
> It's why the patch system has the KernelVersion: tag:
> 
> ?6.?Kernel version.
>     On a separate line, add a tag "KernelVersion: " followed by the kernel
>     version that the patch was generated against. This should be formatted
>     as "KernelVersion: 2.6.0-rmk1"
> 
> This is because that information is relevant for knowing where it should
> be applied, and to which branch.  Having it be something else means I
> have to guess, and that can result in the patch being discarded in this
> manner if I don't find where it's supposed to be applied.
> 
> Yes, I know it's a pain to have to supply this information, but giving
> accurate information there makes things a lot easier and quicker when
> applying patches, rather than playing a game of "guess where it needs
> to be applied, nope, doesn't apply there, try somewhere else."
> 
> Various people in the kernel community have different solutions to this.
> For example, on netdev, it is preferred to state whether you want your
> patch to be applied to "net" or "net-next" by adding that into the
> "[PATCH ...]" tag in the subject line.  It's really about streamlining
> the patch submission and application process.

The tag can take a plain kernel version and a kernel version suffixed
with a shortened git hash (please avoid the full hash, it doesn't
display well with the web presentation, and will probably be truncated
when it's inserted into the database.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Nicolas Pitre]

On Sat, 14 Oct 2017, Russell King - ARM Linux wrote:

> On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > > It should go into your devel-testing branch as this must be applied on 
> > > top of my xip_zdata branch that you merged there.
> > 
> > Thanks, it would've been good to have known that ahead of time.
> > 
> > It's why the patch system has the KernelVersion: tag:
> > 
> > ?6.?Kernel version.
> >     On a separate line, add a tag "KernelVersion: " followed by the kernel
> >     version that the patch was generated against. This should be formatted
> >     as "KernelVersion: 2.6.0-rmk1"
> > 
> > This is because that information is relevant for knowing where it should
> > be applied, and to which branch.  Having it be something else means I
> > have to guess, and that can result in the patch being discarded in this
> > manner if I don't find where it's supposed to be applied.
> > 
> > Yes, I know it's a pain to have to supply this information, but giving
> > accurate information there makes things a lot easier and quicker when
> > applying patches, rather than playing a game of "guess where it needs
> > to be applied, nope, doesn't apply there, try somewhere else."
> > 
> > Various people in the kernel community have different solutions to this.
> > For example, on netdev, it is preferred to state whether you want your
> > patch to be applied to "net" or "net-next" by adding that into the
> > "[PATCH ...]" tag in the subject line.  It's really about streamlining
> > the patch submission and application process.
> 
> The tag can take a plain kernel version and a kernel version suffixed
> with a shortened git hash (please avoid the full hash, it doesn't
> display well with the web presentation, and will probably be truncated
> when it's inserted into the database.)

Probably what you want is the output of 'git describe'.


Nicolas

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Russell King - ARM Linux]

On Sat, Oct 14, 2017 at 11:49:25AM -0400, Nicolas Pitre wrote:
> On Sat, 14 Oct 2017, Russell King - ARM Linux wrote:
> > On Sat, Oct 14, 2017 at 03:14:05PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
> > > > It should go into your devel-testing branch as this must be applied on 
> > > > top of my xip_zdata branch that you merged there.
> > > 
> > > Thanks, it would've been good to have known that ahead of time.
> > > 
> > > It's why the patch system has the KernelVersion: tag:
> > > 
> > > ?6.?Kernel version.
> > >     On a separate line, add a tag "KernelVersion: " followed by the kernel
> > >     version that the patch was generated against. This should be formatted
> > >     as "KernelVersion: 2.6.0-rmk1"
> > > 
> > > This is because that information is relevant for knowing where it should
> > > be applied, and to which branch.  Having it be something else means I
> > > have to guess, and that can result in the patch being discarded in this
> > > manner if I don't find where it's supposed to be applied.
> > > 
> > > Yes, I know it's a pain to have to supply this information, but giving
> > > accurate information there makes things a lot easier and quicker when
> > > applying patches, rather than playing a game of "guess where it needs
> > > to be applied, nope, doesn't apply there, try somewhere else."
> > > 
> > > Various people in the kernel community have different solutions to this.
> > > For example, on netdev, it is preferred to state whether you want your
> > > patch to be applied to "net" or "net-next" by adding that into the
> > > "[PATCH ...]" tag in the subject line.  It's really about streamlining
> > > the patch submission and application process.
> > 
> > The tag can take a plain kernel version and a kernel version suffixed
> > with a shortened git hash (please avoid the full hash, it doesn't
> > display well with the web presentation, and will probably be truncated
> > when it's inserted into the database.)
> 
> Probably what you want is the output of 'git describe'.

Yes and no.  It certainly contains the information, but I think it's
too long.  4.14-rc1-g123456789abc is sufficient - no need for the
leading 'v' and no need for a count of the number of commits between
the tag and the shortened sha hash.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Geert Uytterhoeven]

On Sat, Oct 14, 2017 at 4:14 PM, Russell King - ARM Linux
<linux@armlinux.org.uk> wrote:
> On Thu, Oct 12, 2017 at 11:25:50AM -0400, Nicolas Pitre wrote:
>> On Thu, 12 Oct 2017, Russell King - ARM Linux wrote:
>>
>> > On Tue, Oct 10, 2017 at 01:33:25PM -0700, Tony Lindgren wrote:
>> > > * Geert Uytterhoeven <geert@linux-m68k.org> [171003 11:32]:
>> > > > On Tue, Oct 3, 2017 at 8:15 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > > > > On Tue, Oct 3, 2017 at 8:11 PM, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> > > > >> On Tue, Oct 3, 2017 at 5:37 PM, Nicolas Pitre <nicolas.pitre@linaro.org> wrote:
>> > > > >>> On Tue, 3 Oct 2017, Geert Uytterhoeven wrote:
>> > > > >>> Please send it to RMK's patch system.
>> > > > >>
>> > > > >> Done (I hope so ;-)
>> > > > >
>> > > > > Failed. Retrying.
>> > > >
>> > > > Yiha ;-)
>> > > >
>> > > > http://www.armlinux.org.uk/developer/patches/viewpatch.php?id=8702/1
>> > >
>> > > This also fixes the spamming I started seeing with next-20171009:
>> > >
>> > > Tested-by: Tony Lindgren <tony@atomide.com>
>> >
>> > It's all nice and good that people are testing this patch, but I can't
>> > apply it to -rc1, nor my "misc" branch.  It appears that this is due
>> > to patches going through other trees.
>> >
>> > Sorry, I can't take this patch.
>>
>> It should go into your devel-testing branch as this must be applied on
>> top of my xip_zdata branch that you merged there.
>
> Thanks, it would've been good to have known that ahead of time.
>
> It's why the patch system has the KernelVersion: tag:
>
>  6. Kernel version.
>     On a separate line, add a tag "KernelVersion: " followed by the kernel
>     version that the patch was generated against. This should be formatted
>     as "KernelVersion: 2.6.0-rmk1"
>
> This is because that information is relevant for knowing where it should
> be applied, and to which branch.  Having it be something else means I
> have to guess, and that can result in the patch being discarded in this
> manner if I don't find where it's supposed to be applied.

That's why we have the standard Fixes tag, which was included
Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")

It's trivial for the repo maintainer to know which branch the fix to apply to,
given the Fixes tag.
It's non-trivial to know the branch for the patch submitter, who is forced to
use a non-standard patch submission system.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH] ARM: head-common.S: Clear lr before jumping to start_kernel()

[Russell King - ARM Linux]

On Sun, Oct 15, 2017 at 10:04:16AM +0200, Geert Uytterhoeven wrote:
> On Sat, Oct 14, 2017 at 4:14 PM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > Thanks, it would've been good to have known that ahead of time.
> >
> > It's why the patch system has the KernelVersion: tag:
> >
> >  6. Kernel version.
> >     On a separate line, add a tag "KernelVersion: " followed by the kernel
> >     version that the patch was generated against. This should be formatted
> >     as "KernelVersion: 2.6.0-rmk1"
> >
> > This is because that information is relevant for knowing where it should
> > be applied, and to which branch.  Having it be something else means I
> > have to guess, and that can result in the patch being discarded in this
> > manner if I don't find where it's supposed to be applied.
> 
> That's why we have the standard Fixes tag, which was included
> Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")

Wrong.  You're confusing two different things.

The fixes tag identifies the commit to which the FIX applies.  That's
not what the kernelversion tag described above is for.  That's to
describe where the patch was GENERATED, so that it's easier to know
where it should be applied.

> It's trivial for the repo maintainer to know which branch the fix to
> apply to, given the Fixes tag.
> It's non-trivial to know the branch for the patch submitter, who is
> forced to use a non-standard patch submission system.

So what you're telling me is that you're unable to describe what commit
or the kernel version that the patch was GENERATED against.

I /really/ don't buy such an argument one bit.  If you don't have that
information, by definition you can't generate a git patch.

If it was trivial, then don't you think the patch would've been applied
without all this crap?  The proof is here in this thread, it's not as
trivial as you think it is.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up